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ABSTRACT 



Organizations o-f all types are becoming increasingly 
dependent on the operation of database management systems 
based on one of the three generally knov*jn data models 
(i.e-, network, h i er archi cal , or relational) for the 
centralized control of operational data. As an alternative 
to the development of separate, stand-alone systems for 
specific models, recent research has proposed a sv'stem 
designed to support multiple data models and model— based 
languages as if the system is a heterogeneous collection of 
database systems- This proposal is based on the existence 
of a simple and powerful data model to which the three well- 
known models can be mapped- This model, the attr i but e-based 
data model, is the data model upon which the (iui t i -Bac kend 
Database System (MDBS) , a software database machine, is 
based- This thesis concentrates on the language interface 
aspects of i mpl emenri ng MDBS as a kernel for the support of 
relational databases- In particular, this thesis provides 
the design and analysis of an interface between the 
relational query language (SQL) and the at tr i bute— based data 
language (ABDL) . 
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I- 



INTRQDUCTIQN 



Database technology is rapidly becoming an extremely 
important aspect of data processing- Commercial database 
management systems have only been available since the 
1960's- Today, many thousands of or gani z at i ons (e-g-, 
corpor at i ons , universities, governments) are critically 
dependent on the efficient and reliable operation of these 
systems- Each of these organa zat i ons has invested large 
amounts of time, energy, and money to ensure that the 
various end users are provided the data they need for doing 
their jobs as effectively and efficiently as possible- Any 
of the three generally known approaches to the design of 
database systems (i-e-, netv^ork, hi erar chi cal , and 
relational) provides for the centralized control of an 
organization's operational data- However, questions 
concerning the ease of under stand i ng , use, and 
implementation have stimulated research to determine the 
"best" approach- The earliest database systems were based 
on the network or the hierarchical model- These models lend 
themselves well to the efficient implementation necessary 
for the maintenance of large databases- Today, with the 
increased emphasis on the ease of use and understanding, 
many of the newer commer ci al i z ed systems are based on the 
relational model- Examples of commercially available 



systems based on these models include: IMS (hi erar chi cal ) , 
SQL/DS (rel at i onal ) , and IDMS (network). Each ot these 
systems utilizes a model— based data language which allows 
the user to specify the operations to be performed on the 
data- 

□nce a commitment is made to manage a large database 
containing an organi zat i on ' s operational data through the 
implementation of one of these systems, it is financially 
prohibitive to change to another approach- In addition to 
the obvious re— programmi ng requirement, user personnel 
(including high-level executive users) must be re-trained in 
the syntax and semantics of a different data language. 
Demurjian, et. al - , have proposed an attractive alternative 
to the development of separate, stand— alone systems for 
specific models. Their research , reported in CRef . ID, 
proposes that a system can be designed " . - - to support 
multiple data models and model-based languages as if the 
system is a heterogeneous collection of database systems.'* 

The above proposal is based on the existence of a simple 
and powerful data model to which the network, hi erarchi cal , 
and relational models can be mapped. This is the attribute- 
based data model as originally described by Hsiao CRef. 2D 
and extended by Wong CRef. 31. This is the data model of 
the Mul t i — bac kend Database System (MDBS), a software 
database system designed by Menon and Hsiao CRef. 41. 
The proposal of CRef. 11 is that the attr i bute— based system 
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(MDBS), with the attri but e~based data model and the 
attri but e-based data language (ABDL) , can serve as a kernel 
for the support of several data models and the data 
languages based on those models. 

The attri bute— based system is ideally suited to its 
proposed role as a kernel of database systems. As 
demonstrated by Banerjee CRefs- 5, 6, and 71, a relational, 
hi erarchi cal , or network database can be converted into an 
attri bute— based database. The primary database and 
aggregate operations, RETRIEVE, INSERT, DELETE, UPDATE, MIN, 
MAX, SUM, COUNT , and AVG are supported by the system's high- 
level data language, ABDL- Finally, language interfaces can 
be developed to translate relational, hi er ar ch i cal , or 
network data language constructs into ABDL constructs. In 
this thesis, we are concerned with the language interface 
aspects of this research- 

In particular, this thesis provides the design and 
analysis of a relational interface to the attri bute— based 
system (MDBS). We extend the work of Macy CRef- 81, who has 
shown that a subset of the relational model— based data 
language, SOL (Structured Query Language) can be directly 
supported by MDBS and ABDL- Macy has provided mappings from 
the SQL SELECT, INSERT, DELETE, and UPDATE constructs to the 
corresponding ABDL constructs: RETRIEVE, INSERT, DELETE, 
and UPDATE- The translations are limited to queries 
involving simple, si ngl e— rel at i on operations. Using these 
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basic mappings as a -foundation, we show that SQL queries 
involving set membership operations can also be mapped 
directly to ABDL constructs. We also demonstrate that other 
SQL constructs (o-f particular importance, the nested SQL 
SELECT) can be mapped to a series o-f ABDL operations. 
Finally, we propose a software structure to facilitate the 
implementation of a complete relational interface for the 
attr i bute-based kernel <i.e., MDBS). In the following two 
sections, we discuss our design goals and our uncon vent i onai 
approach to the design of the SQL interface. In the last 
section of this chapter , the organization of the thesis is 
presented . 



A. DESIGN GOALS 

We are motivated to design a SQL interface to MDBS in 
order to demonstrate the feasibility of utilizing the 
attr i bute— based system as the kernel of database systems in 
general- However, our intention is not to propose changes 
to MDBS itself. Instead, we propose that the SQL interface 
be implemented on the host computer. All translations are 
accomplished in the SQL interface. MDBS continues to 
receive and process requests written in the syntax of ABDL. 

Related to the goal of avoiding modi f i cat i ons to the 
f unct i onal i ty of MDBS is the goal of keeping the syntax of 
ABDL intact. We utilize existing ABDL constructs in our 
query tr ansi at i ons . A single SQL query may map to one ABDL 
request or a series of ABDL requests- The processing of one 
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request may depend on the results of some other request in 
the series. Clearly, the interface must include some method 
of controlling the iterative processing of series of 
requests. The software structure of our proposed interface 
(described in Chapter VI and augmented in Chapter VII) 
provides for this iterative control . 

As discussed above, we have made it our goal to leave 
MDBS and ABDL unchanged. We also desire to make our 
interface transparent to the SQL user. For example, in a 
corporate environment, a new employee with previous 
experience with SQL/DS should be able to log in at a system 
terminal , input a SDL request, and receive result data in a 
relational format (i.e. , a table). The employee requires no 
training in MDBS or ABDL procedures prior to utilizing the 
system- An obvious advantage is that the new employee 
becomes a contributing member of the organization almost 
immediately, with no retraining. The non-productive period 
of new employee i ndoctr i nati on is greatly reduced. 

B. APPROACH TO DESIGN 

Our approach to the design and analysis of a SQL 
interface to MDBS is unconvent i onal by today's standards. 
The normal method is to design a system in a top-down 
manner. High-level abstractions are considered first, while 
deferring lower— level details. In this thesis, we consider 
the lowest levels first- We are building upon the basic 
subset of SQL-to-ABDL mappings provided by Macy CRef. 83- 
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As additional SQL operations are incorporated into 
the interface, we make appropriate additions to the set of 
SQL~to~ABDL mappings. The functional requirements of an 
overal 1 software structure for the interface become apparent 
in Chapter V, when we present ABDL translations for the 
nested SQL SELECT. The f unct i onal i ty and organization of 
structure components is described graphically, in text, and 
through the presentation of high-level algorithms. We 
reiterate that, in the development of the SQL interface, 
MDBS is considered to be a "black box" which processes 
database requests presented in the syntax of ABDL. We are 
proposing an interface, residing on a host computer, which 
enables a user to access a relational database implemented 
on an attr i bute-based system. Recommendations for 
modification within the structure of MDBS are made only if a 
desirable SQL operation cannot be supported by existing ABDL 
oper ati ons. 

Our approach to the presentation of SQL— to— ABDL mappings 
is as follows. We first review the direct mappings (i.e. , 
SELECT/RETRIEVE , I NSERT/ I NSERT , DELETE/DELETE , and 
UPDATE/UPDATE) developed by Macy CRef. 8H. Beginning in 
Chapter IV, we investigate additional operations to be 
supported by the interface. The f unct i onal i ty of each of 
these operations is thoroughly explained through the use of 
example queries. The equivalent ABDL requests are then 
determi ned . 
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All examples on database operations presented in this 
thesis are based on the Suppl i ers— and— Part s database 
depicted in Date ERe-f. 9H. This database contains three 
relations: "S" (Suppliers), "SP" (Shipments), and "P" 
(Parts). We use many o-f Date's examples directly because 
they are well-known, thereby -facilitating reader 
understandi ng of our SQL to ABDL tr ansi at i ons . The database 
is depicted in Figure 1. 



C. DRGANIZATIDN QF THE THESIS 

In Chapter II, we present an overview of the 
organization and functionality of the Mul t i — bac kend Database 
System (MDBS). Also presented are descriptions of the 
attr i bute— based data language (ABDL) and the relational data 
language (SQL). Chapter III reviews the direct SQL— to- 
ABDL mappings as developed by Macy ERef. 81. SQL set 
membership operations involving single relations, and the 
equivalent ABDL requests are explained in Chapter IV. 
Chapter V explains set membership operations on multiple 
relations (i.e., nested SELECT). In Chapter VI, a software 
structure is proposed to facilitate the implementation of 
nested SELECTs. In Chapter VII, the interface software 
structure is modified to include the functionality necessary 
to accomplish the translation of other si ngl e— rel at i on and 
mul t i pi e— rel at i on operations. Chapter VIII presents our 
conclusions and recommendati ons for future research. 
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Figure 1- The Suppl i ers-and— Parts Database- 
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II. 



THE MULT I -BACKEND DATABASE SYSTEM (MDBS) . ITS DATA 
LANGUAGE (ABDL) AND THE INTERFACE LANGUAGE (SQL) 

As we begin our i nvest i gat i on into the -feasibility o-f 
designing and implementing a complete relational inter-face 
-for the Mul ti —backend Database System (MDBS), it is 
important to gain a general -familiarity with the 
organization o-f MDBS and with the system's attr i bute— based 
data language (ABDL). We have selected the Structured Query 
Language (SQL) as the relational data language to be 
supported by our inter-face. There-fore, we must also have an 
understandi ng o-f the structure and capabilities o-f this 
1 anguage. 

In Sections A and B, we brie-fly describe MDBS and ABDL, 
respectively. Section C provides a brie-f description o-f 
SQL- These descriptions, though somewhat super-f i ci al , 
should enable the reader to com-fortably -follow subsequent 
discussions. A complete description o-f MDBS and ABDL can be 
-found in Hsiao CRe-fs. 4 and lOH. The reader is re-ferred to 
Astrahan CRe-f. IID and Chamberlin CRe-f. 12D -for in— depth 
discussions o-f SQL. 

A. A REVIEW OF THE MULT I -BACKEND DATABASE SYSTEM (MDBS) 

MDBS is a mul t i pi e— mi ni computer backend database 
computer- O-f -f -t he-shel -f hardware and specialized so-ftware 
are combined to provide database management service to a 
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host computer. Figure 2 depicts the hardv*^are organization 
of MDBS- The hardware organization includes one 
minicomputer as a control 1 er and multiple minicomputers as 
backends- Each backend has one or more dedicated disk 
drives- The controller and the backends are connected by a 
broadcast bus. The database is distributed across the disk 
drives of the backend in such a manner that the backends can 
process requests in parallel, providing a significant 
performance advantage over traditional si ng 1 e'-pr ocessor 
archi tectur es. 

The prototype MDBS, currently operating at the U.S. 
Naval Postgraduate School, uses a VAX 11/780 as the 
controller and two PDP ll/44s as the backends- Each of 
these backends has one or more disk drives for its dedicated 
use- The multiple backends and the controller are connected 
by DEC'S Parallel Communi cat i on Links (PCLs) - Their 
broadcast capabilities are simulated in software- 

The major design goal of MDBS is to provide a high- 
performance system for 1 ar ge— capac i t y databases- Throughput 
improvement should be proportional to the number of 
backends, and the r esponse— t i me reduction should be 
inversely proportional to the number of backends- A second 
design goal is that the system should be easily extensible- 
The system should be able to accomodate additional backends 
with no modification to existing software, and no new 
programming- The i ncor por at i on of additional backends 
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Figure 2- The MDBS Hardware Organization 
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should not require modification to existing hardware, 



and 



disruption of system activity should be minimal- The 
software structure of MDBS provides this extensibility. The 
software of the backends is identical, utilizing identical 
operating software for the additional backends. 

It is clear that the controller could become a 
bottleneck. MDBS reduces this potential by minimizing the 
role of the controller and maximizing the amount of work 
done by the backends. The software structure of MDBS is 
shown in Figure 3. The functions of the controller are 
limited to request preparation, insert information 
generation, and post processing- The request prepar at i on 
f unct i ons are performed before a request is placed on the 
broadcast bus. These functions handle parsing, syntax 
checking, and the tr ansf ormat i on of a parsed request into 
the form required for processing at the backends. The 
i nser t i nf ormat i on qener at i on f unct i ons are performed during 
the processing of an insert request. These functions 
provide additional information to the backends, such as the 
identity of the particular backend at which the record is to 
be inserted- The post pr ocessi nq f unct i ons are performed 
after replies are returned from the backends- For example, 
result data are collected prior to forwarding to the host 
computer - 

As described above, the controller does relatively 
little work. The backends, on the other hand, are 



The Mui ti -Backend Database System 
(MDBS) 




Figure 3 



The MDBS Sottware Structure 



responsible for all the major database management functions. 
These are directory management, record processing, and 
concurrency control . The di rector y management f unct i ons 
determine the secondary storage addresses of the appropriate 
records and perform directory table maintenance. The r ecord 
processing functions store records into secondary storage, 
retrieve records from secondary storage, and select the 
records that contain the desired information. The 
concur r ency control f unc t i ons ensure consistency for 
concurrent e>tecution of user requests. 

The key to h i gh— per f or mance is in the parallelism of the 
backends. The database is distributed across the disks of 
all of the backends. Therefore, when a request is 
broadcasted from the controller, each backend can execute 
the request on its portion of the database. To yield an 
additional performance advantage, a queue of requests is 
maintained at each backend- Each backend schedules requests 
for execution independent of the activities of the other 
backends. 

B- THE ATTRIBUTE-BASED DATA LANGUAGE (ABDL) 

We preface our discussion of the syntax and 
functionality of ABDL with a brief introduction to the data 
model supported by MDBS- This model is the attr i but e— based 
data model, originally developed by Hsiao CRef. 2!1. The 
following constructs are informally defined- A database 
consists of a collection of files- Each file contains a 
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unique group of records. 



Each record is composed of two 



parts- The first of these parts is a collection of 
attr i bute—val ue pai rs or keywords . An attr i bute— vai ue pair 
is an element of the Cartesian product of the attribute name 
and the domain of attribute values. As an example. 
<STATUS,30> is an attr i bute-val ue pair having 30 as the 
value for the STATUS attribute. In each record , there is at 
most one attr i bute— val ue pair for each distinct attribute 
defined in the database. The last part of each record 
contains textual information. This is the record body . An 
example of a record without a record body is shown belov-^. 
We note that all examples in this and subsequent sections 
are based on Date's suppl i er s— and— par ts database as 
described in CRef 93 and in Chapter I. 

( <FILE , S> , <S# , Si > , <SNAME , Smi th > , <STATUS , 20> , <C ITY , London > ) 

The first attr i bute-val ue pair in every record indicates the 
file name. In the example above, the file name is 'S' (the 
Suppliers file). 

The database can be accessed through the use of keyword 
predi cates . Each of these keyword predicates is a three- 
tuple of the form (attribute, r el at i onal _oper ator , value), 
e-g., (STATUS < 30). When keyword predicates are combined 
into a conjunction such as 

((FILE = S) A (STATUS < 30)) 
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or into a disjunction of conjunctions such as 



(((FILE = S) A (SNAME = Smith)) V 
((FILE = S) A (SNAME = Jones))) 

a query (in disjunctive normal form) of the database is 
formed - 

In the following subsections, we will see how these 
keyword predicates and queries are used in the attribute- 
based data language for search and retrieval operations. We 
describe the syntax and functionality of the four types of 
request supported by ABDL: retrieve, insert, delete, and 

update. Appendix A provides a formal specification of this 
non— procedural language. 

1 . The RETRIEVE Request 

The RETRIEVE request allows the user to query the 
database for information. This operation obtains the 

requested data without altering the database. The syntax 
i s: 

RETRIEVE (Query) <Target-l i st > CBY attribute! CWITH Pointer! 

The type of the request is indicated by the reserved word 
RETRIEVE. As we have seen, the Query part is composed of 
predicates in the disjunctive normal form. From our 

previous discussion, we note that the Query specifies the 
file and those records within the file which satisfy the 
request. The attributes for which values are to be 
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extracted -from this portion of the database are contained in 
the Target-list. ABDL supports five aggregate operations: 
AV6, COUNT, MAX, MIN, and SUM- Therefore, the attribute 
value may be an aggregate of values from multiple records, 
or the value from a single record- 

The BY and WITH clauses are optional, as indicated 
by the square brackets in the syntax. The BY— clause is used 
when a grouping by some attribute is desired- The WITH— 
clause specifies whether pointers to the retrieved records 
must be returned to the user for later use in an update 
request- As an example of a RETRIEVE request, if we wish to 
obtain supplier nam.es for all of the suppliers with STATUS 
greater than 10, grouped by location, we may use the 
following query: 

RETRIEVE ((FILE = S) A (STATUS > 10)) <SNAME> BY CITY 
2- The INSERT Request 

The INSERT request alters the database by adding a 
new record- The syntax is: 

INSERT Record 

An example of an INSERT request is: 

INSERT ( <FILE,S.>, <S#,S1>, <SNAME , Smi th > ) 

This adds a record to the suppliers file for supplier number 
SI and identifies that supplier as Smith- 
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The DELETE Request 



The DELETE request alters the database by removing 
an existing record or records- The syntax is: 

DELETE Query 

where Query specifies which records are to be deleted- An 
example of a DELETE request is: 

DELETE ((FILE = S) A (STATUS = 10)) 

This deletes all records in the suppliers file for suppliers 
whose status is equal to 10- 
4- The UPDATE Request 

The UPDATE request alters the database by modifying 
the value of some attribute in an existing record- The 
syntax is: 



UPDATE Query Modifier 

where Modifier indicates which of five types of modification 
is to be performed- These modifiers are defined as follows- 
A type— O modi f i er sets the new value of the attribute being 
modified to a constant- A type— I modi f i er sets the new 
value of the attribute to be some function of its old value 
in the record being modified- A type— 1 1 modi f i er sets the 
new value to be some function of another attribute value in 
the record being modified- A type— III mod i f i er sets the new 
value to be some function of another attribute value in 
another record identified by the Query in the modifier- A 
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type IV modi f i er sets the new value to be some function of 
another attribute value in another record identified by the 
pointer in the modifier. An example of an UPDATE request 
(using a type-'I modifier) is: 

UPDATE (FILE = S) <STATUS = STATUS + 10> 
which adds 10 to the status of all suppliers- 

C. THE RELATIONAL QUERY LANGUAGE (SQL) AS THE INTERFACE 

LANGUAGE 

AS indicated in Chapter I, we have selected the 
Structured Query Language (SQL) as the data language to be 
supported by our relational interface to the Mul ti -backend 
Database System (MDBS). The language's commercial 
availability coupled with its simple yet powerful 
functionality make SQL an ideal choice. 

In the preceding section, we described the attribute- 
based data model prior to introducing ABDL. However, in 
this section, we assume a certain familiarity with the 
relational data model as we prepare to describe the four 
basic constructs of SQL: SELECT, INSERT, DELETE, and 
UPDATE. If the reader desires a review of relational 
theory, there are several very good texts available. In 
particular, we recommend Date CRef. 9U and Ullman CRef. 13]l- 
A discussion of the mapping between the relational data 
.model and the attri bute— based data model can be found in 
Banerjee CRef. 61. 
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The SELECT Query 



1 . 

Data retrieval, which is represented syntact i cal 1 y 
as a SELECT— FROM— WHERE block, is the most basic operation o-f 
SQL. Mapping indicates that a known quantity (STATUS = 30) 
is to be transformed into a desired quantity (SNAME) by 
means of a relation (S) . The attributes to be returned are 
listed in the SELECT clause (the built-in functions COUNT, 
SUM, AVG, MAX, and MIN may be applied to these attributes). 
The FROM clause indicates which relation or relations are to 
be searched. The WHERE clause specifies the retrieval 
conditions. As an example, if we desire to obtain the names 
of suppliers whose status is 30, we may use the following 
query: 

SELECT SNAME 

FROM S 

WHERE STATUS = 30 

The SELECT construct allows the user great 
flexibility in data retrieval operations. The user can list 
several relations in the FROM clause in order to obtain 

values selected from more than one relation (JOIN 

operations). The WHERE clause can contain any number of 
predicates including the six standard relational operators 
( = , t 1 t ^nd < = ) , and the Boolean operators (AND, 

OR, and NOT). Parenthesis may be used to indicate a desired 

order of evaluation. The set comparison operators IN, ANY, 
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and ALL may also be used in the WHERE clause. <We 
investigate the use of these operators in Chapter IV.) 

There are many other possible variations to the 
SELECT operation including the extremely useful nested 
SELECT. In the nested SELECT, the result of one SELECT 
request is used in the WHERE clause of another SELECT 
request. (The nested SELECT is thoroughly described in 
chapter V. ) 

2. The INSERT Query 

The INSERT request allows the user to insert a new 
tuple (row) or set of tuples into an existing relation 
(table). Insertion of a single tuple can be accomplished 
through the use of a query such as 

INSERT INTO S: 

< ' S6 ' , ' Rol 1 i ns ' , ' 40 ' , ' Newport ' > 

In this example, all of the attributes are present and in 
the correct order. If some attribute values are unknown, 
those attributes for which values are being inserted must be 
listed following the relation name. A SQL INSERT statement 
may also evaluate a SELECT request and insert the resulting 
set of tuples into an existing (or temporary) relation. An 



example of such an INSERT operation is as follows. 



INSERT INTO TEMP: 



SELECT P# 

FROM SP 

WHERE S# = 'S2' 

This enters into TEMP part numbers for all parts supplied by 
suppl i er S2- 

3- The DELETE Query 

The DELETE specifies tuples to be removed from the 
database- The tuples are indicated by means of a WHERE 
clause that is synt act i cal 1 y identical to the WHERE clause 
of a SELECT construct- As an example, to delete supplier 
number five from the supplier relation, we may use the 
following query- 

DELETE S 

WHERE S# = 'S5' 

We may also delete all shipments with the query 

DELETE SP 

The SP relation is still known, but it is now empty- 

4- The UPDATE Query 

The UPDATE request is synt act i cal 1 y similar to the 
DELETE request, except that a SET clause is used to specify 
the updates to be made to the selected tuples- New 

attribute values contained in the SET clause may be stated 
as constants, as expressions based on the original value of 
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the attribute 



or 



as 



An eK ample o-f an 



nested queries- 

UPDATE request is 

UPDATE S 
SET STATUS = 2 ♦ STATUS 

WHERE CITY = 'London^ 



This doubles the status o-f 



all suppliers in London. 






III. 



REVIEW OF BASIC MAPPIN65 



As we have described in Chapter II, the -Four primary 
database operations of the Structured Query Language (SQL) 
are SELECT, INSERT, DELETE, and UPDATE. Macy CRef. 31 has 
shown that for a subset of simple, si ngl e— r el ati on SQL 
queries of all four types, there exist direct mappings into 
requests of the Attr i bute— based Data Language (ABDL) . These 
mappings are fundamental to all further SQL-to— ABDL 
translations introduced in this thesis. Therefore, in the 
remainder of this chapter , we provide a review of these 
basic mappings as defined by Macy. We explain the mappings 
both graphically and in text. Each graphical presentation 
will display the general forms of the SQL and ABDL 
constructs, and the mappings between them (such as Figure 4, 
which depicts the SELECT to RETRIEVE mapping). Sample 
transl at i ons , utilizing our supp 1 i er s— and-par ts database, 
will be presented in the text- The subset of SQL, for which 
translations are described, contains those operations that 
Macy has determined can be directly supported by MDBS and 
ABDL. In the next chapter , we will show that SELECT 
requests involving set comparison operators can also be 
directly supported- In subsequent chapters, we describe 
translations for SQL constructs such as the nested SELECT 
which involve multiple ABDL constructs. 



34 



Prior to describing the specific SQL to ABDL mappings 



(s.g., SELECT to RETRIEVE), we discuss two general types of 
mapping identified by Macy: Syntact i c— subst i tut i on mapping 

and Conversion mapping- Syntact i c— subst i tut i on mappings are 
accomplished by simple substitution of syntactical terms- 
Mappings requiring oniy substitution are denoted by a 
directional arrow labeled with a square containing the 
letter S (e-g- , the mapping between the reserved words 
SELECT and RETRIEVE in Figure 4). Conver si on mappings are 
accomplished by combining a clause from an SQL query with 
information about the ABDL data structure to create the 
equivalent clause of the ABDL construct- Mappings requiring 
conversion are denoted by a directional arrow labeled with a 
triangle containing the letter C (e-g-, the mapping between 
the SQL FROM and WHERE clauses to the ABDL Query in Figure 
4). We will describe conversion mappings in more detail as 
•we present each for the SQL to ABDL tr ansi at i ons - For an 
extensive discussion of the basic mappings described in this 
chapter , the reader is referred to Macy CRef- 83- 

A- MAPPING THE SQL SELECT QUERY TO THE 

ABDL RETRIEVE REQUEST 

The mapping from the SQL SELECT to the ABDL RETRIEVE is 
depicted in Figure 4- The mapping proceeds as follows- 
The reserved word SELECT is mapped by syntactic substitution 
to the reserved word RETRIEVE- The sel _expr _1 i st maps 
directly to the target_list- A conversion mapping is 
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required to translate the FROM and WHERE clauses to the ABDL 



query clause- This is accomplished by creating an equality 
keyv^or d~pr edi cate -for the r el at i on_name , e.g., FILE = 

rei at i on_name. This new predicate is combined with the 



SELECT 




CBY attribute!] 



Figure 4. Mapping the SQL SELECT to the ABDL RETRIEVE 

other predicates listed in the boolean expression to form an 
equivalent ABDL query clause. This conversion is called a 
query-conver si on mappi nq . The GROUP BY construct maps 
directly to the BY construct. As an example of a SELECT to 
RETRIEVE translation, the following SQL SELECT will, for 
each part supplied, get the part number and the total 
quantity supplied of that part. 



SELECT 



P#,SUM(QTY) 



FROM SP 

GROUP BY P# 

An equivalent ABDL request is 

RETRIEVE (FILE = SP) <P# , SUM (QTY ) > BY P# 

B. MAPPING THE SQL INSERT QUERY TO THE ABDL INSERT REQUEST 
The mapping -From the SQL INSERT to the ABDL INSERT is 
depicted in Figure 5. The mapping proceeds as -follows. The 
reserved word INSERT is the same -for both requests. A 
conversion mapping, referred to as a r ecor d— conversi on 
mapping , in this case, is required to translate "INTO 
rel ati on_name insert_spec" into the ABDL "record". As we 
have seen in Chapter II, the ABDL record is a series of 
attr i bute— val ue pairs, the first pair of which identifies 
the file name. This mapping, then, can be accomplished by 



INSERT 






INTO relation name 

i nser t_spec 



INSERT 




Figure 5- Mapping the SQL INSERT to the ABDL INSERT 



constructing attr i bute—val ue pairs for the rel at i on /f i 1 e and 
rel at i on/f i 1 e name and for the values of the attributes 
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listed in the insert_spec. As an example of an SQL INSERT 
to ABDL INSERT translation, the following SQL INSERT query 
will add part P7 (name 'Washer', color 'Grey', weight '2', 
city 'Athens') to rel at i on/f i 1 e P. 

INSERT INTO P: 

< ' P7 ' , ' Washer ' , ' Grey ' , ' 2 ' , ' Athens ' > 

An equivalent ABDL request is 

I NSERT ( < F I LE , P > , < P# , P7 > , < PNAME , Wash er > , 

<C0L0R,Grey>,<WEIGHT,2>,<CITY, Athens>) 

C. MAPPING THE SQL DELETE QUERY TO THE ABDL DELETE REQUEST 
The mapping from the SQL DELETE to the ABDL DELETE is 
depicted in Figure 6 The mapping proceeds as follows- The 
reserved word DELETE is the same for both requests- 
The query— conversi on mapping, as described in Section A, 



DELETE 




DELETE 



relation name 




C WHERE 



bool ean 1 



Figure 6- Mapping the SQL DELETE to the ABDL DELETE 



is used to translate "rel at i on_name" and "WHERE boolean" 
into the ABDL query clause. As an example of an SQL DELETE 
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to ABDL DELETE translation, the following SQL DELETE query 
will delete supplier SI from the suppliers relation- 



DELETE S 
WHERE S# ='S1' 



An equivalent ABDL request is 

DELETE ((FILE = S) A (S# = Sl>) 

D. MAPPING THE SQL UPDATE QUERY TO THE ABDL UPDATE REQUEST 
The mapping from the SQL UPDATE to the ABDL UPDATE is 
depicted in Figure 7- The mapping proceeds as follows. 



UPDATE 



V 

UPDATE 



relation name 




C WHERE 



bool ean 1 



Figure 7. Mapping the SQL UPDATE to the ABDL UPDATE 

The reserved word UPDATE is the same in both requests. As 
in Sections A and C, the query— conver si on mapping is used to 
translate "r el at i on_name" and "WHERE boolean" into the ABDL 
query clause. This conversion is common to the 
SELECT/RETRIEVE, DELETE, and UPDATE tr ansi at i ons . The 



39 



component “set _c 1 ause_i i st " directly correlates to the ABDL 



"modifier’*, i.e., both constructs specify how the records 
being modi-fied are to be updated. To accomplish this 
translation, the modi -F i er conversi on mapping is used. 
The conversion required is a r est ructur i ng o-f SQL 

set_cl ause_l i st constructs into acceptable ABDL format- The 
modi f i er— conversi on is similar to the query— conversi on . We 

now present an example of the conversions that are required 
in the translation of an SQL UPDATE to an ABDL UPDATE. If 
we desire to double the status of all suppliers in london, 
we may use the following SQL query: 

UPDATE S 

SET STATUS = 2 * STATUS 

WHERE CITY = 'London' 

An equivalent ABDL request is 

UPDATE ((FILE = S) A (CITY = London)) (STATUS = 2 * STATUS) 
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IV. SELECTIONS WITH SET MEN8ERSHIP OPERATIONS ON 
SINGLE RELATION S 



As 


we have 


seen , 


the condition 


f ol 1 owi ng 


the WHERE 


cl ause 


in SQL 


SELECT 


operations may 


i nc 1 ude 


the normal 



comparison operators, i.e., =, , etc. Macy CRet. B1 has 
shown that MDBS supports simple, si ng i e-rei at i on retrieval 
operations using these comparison operators. SQL allows the 
use of several additional comparison operators. Three of 
these, IN, ANY, and ALL, deal with the set membership, and 
are of particular interest to us as we investigate possible 
extensions to the subset of SQL operations whose interfaces 
were proposed by Macy. 

In this chapter we show how qualifications using IN, 
ANY- and ALL can be supported by MDBS. We first consider 
the simple case where set members are enumerated in the 
query- Some of the examples we provide herein may not 
appear very useful. However, they will serve to illustrate 
the mechanics of SELECT operations using these comparison 
operators- Their usefulness v-vi 1 1 become apparent in Chapter 
V, when we use them in retrievals involving multiple levels 
of nesting. 

In sections A, B, and C, we formally define the 
comparison operators IN, ANY, and ALL, respectively. As 
noted by Chamberlin, et - ai - CRef- 14D, English language 
definitions of these operators are, at best, ambiguous- We 
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shall, nevertheless, attempt to explain them in text prior 
to providing a clarifying definition in predicate logic. An 
example of a SELECT query will then be given for each case. 
The result relation of each of these examples will be 
provided in order to further clarify the uses of these 
operators. As in previous chapters, our examples specify 
retrievals of data contained in Dates database (defined in 
Chapter I). We will continue to utilize this database 

throughout this thesis. Again, note that some of our 
examples are taken directly from Date CRef. 9H. In Sections 
D, E, and F we express IN, ANY, and ALL i n the ABDL 
requests. 

A. IN-MEMBERSHIP OPERATIONS 

The comparison operator, IN, can be thought of as the 
set membership operator, G . Corr espondi ngl y , NOTHIN is 



condition, A IN B, evaluates to be true if and only if the 
value of attribute A is equal to at least one value in the 



equivalent to 




1 - The Set Member shi p Oper ator , 'IN' 



The operator , IN, is evaluated as follows. The 



enumerated set B. The formal definition in predicate logic 



foil ows : 
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EXAMPLE i: It we wish to obtain supplier numbers tor 

suppliers Smith and Jones, we may use the 
■following query: 



SELECT S#,SNAME 
FROM S 

WHERE SNAME IN ( Smi th , Jones ) 



The result relation is: 



3# 


SNAME 


51 

52 


Smi th 
Jones 



2- The Set Member shi p Oper ator , ' NOT IN ' 

The operator , NOTHIN, is evaluated as -follows. The 
condition, A NOT_IN B, evaluates to be true i -f and only if 
the value of attribute A is not equal to any value in the 
enumerated set B- The formal definition in predicate logic 
foil ov*^s : 

V>» ( X G A < == > Vy ^ y E I '< y ^ ^ 

EXAMPLE 2: If we wish to obtain supplier numbers for 

suppliers who supply some parts, but do not 
supply parts P3 or P4 , we may use the following 
query: 

SELECT S# 

FROM SP 

WHERE P# NOT IN (P3,P4) 
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The result relation is: 



S# 



52 

53 



B. ANY-MEMBERSHIP OPERATIONS 

The comparison operator , ANY, is used in conjunction 
with the six standard relational operators, =, , <=, >= , 

<, and >. It speci-fies variations on the theme of set 
membership as explained in the following subsections. 

The Set Member shi p Operator , ' =AMY ' 

The operator, =ANY , is i nt er changeab 1 e with the 
operator, IN. The condition, A =ANY B, evaluates to be true 
if and only if the value of attribute A is equal to at least 
one value in the enumerated set B. Example 1 and the 
predicate logic definition given for the operator IN apply 
equally to =ANV'. In subsequent examples involving set 

membership, we shall use IN rather than =ANY. 

2- The Set Membership Qper ator , ' ""=ANY ' 

The operator , "■'=ANY , is evaluated as follows- The 

condition, A '^=ANY B, evaluates to be true if and only if 
the value of attribute A is not equal to at least one value 
in the enumerated set B- The formal definition in predicate 
1 ogi c foil ows: 

\/x (x C A <==> ^y <y £ B | x y) ) 

EXAMPLE 3: If we wish to obtain supplier numbers for 

suppliers who supply some parts, but do not 
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supply both parts PI and P2 , 



we may use the 



-following query: 



SELECT S# 

FROM SP 

WHERE P# (P1,P2) 



The result relation is: 



S# 



53 

54 



3- The Set Membership Operator , " <=ANY ' 

The operator, <=ANY, is evaluated as -follows. The 
condition, A <=ANY B, evaluates to be true if and only if 
the value of attribute A is less than or equal to at least 
one value in the enumerated set B. This implies that the 
value of attribute A is less than or equal to the maximum 
value in the set B. <=ANY, then, is not particularly useful 
in the case of enumerated sets. The operators >= , >, and < 

are similarily of limited value when sets are enumerated in 
the query. As previously stated, the usefulness of these 
operators will become apparent when we discuss queries in 
which the results of one SELECT operation determine the set 
members in the WHERE clause of another SELECT operation 
(nested SELECT). The formal predicate logic definition of A 
<=ANY B follows: 

Vx (k e A <==> ^y (y 6 B j x <= y) ) ==> 

V>^ (x 6 A <==> X <= max f B> ) 
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As can be seen -from the predicate logic definition, when 
using the operator , <=ANY, it is logically unnecessary to 
list more than one value (the maximum value) in the 
enumerated set B. A similar comment is applicable when 
using >=ANY , <ANY, or >ANY- However, in anticipation of our 
nested SELECT discussion in Chapter V, example queries 
utilizing these operators will each contain an enumerated 
set having more than one member. The additional values 

listed in the set are superfluous. However, they will help 

demonstrate the differing results obtained through the use 
of the ANY and ALL operators. 

EXAMPLE 4: If we wish to obtain supplier names for 

suppliers whose status is not larger than 30, 
we may use the following quer\'; 



SELECT SNAME 



FROM S 

WHERE STATUS <=ANY (10,20,30) 



The result relation is: 



SNAME 



Smi th 
Jones 
Blake 
Clark 
Adams 



The Set Membershi p Operator , ' >=ANY ' 

The operator >=ANY is evaluated as follows. The 
condition A >=ANY B evaluates to true if and only if the 
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value of attribute A ie greater than or equal to at least 
Qi-jo value in the enumerated set B- This implies that the 
value of attribute A is greater than or equal to the minimum 
value in the set B. The formal definition in predicate 
logic follows: 



^ <==> <y £ B I X >= y> ) ==> 

V>' (x E A <==> X >= min <!B> ) 

EXAMPLE 5: If we wish to get supplier names for suppliers 

whose status is not less than 10, we may use 
the following query: 



SELECT SNAME 
FROM S 

WHERE STATUS >=ANY (10,20,30) 



The result relation is: 



SWAME 



Smi th 
Jones 
Blake 
Cl ark 
Adams 



5. The Set Member shi p Operator , ' <AMY " 

The operator , <ANY, is evaluated as follows. The 
condition, A <ANY B, evaluates to be true if and only if the 
value of attribute A is less at least one value in the 
enumerated set B- This implies that the value of attribute 
A is less than the maximum value in set B. The formal 
predicate logic definition follows: 
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names -For 



(;; e A <==> 3v <y e B ) >; < y) ) ==> 

V< e A <==> >: < ma>: <:B> ) 

EXAMPLE 6: If we wish to obtain supplier 

suppliers whose status is less than 30, we may 
use the following query: 



SELECT SNAME 
FROM S 



WHERE STATUS <ANY (10,20,30) 



The result relation is: 



SNAME 



Smi th 
Jones 
Cl ark 



6- The Set Member shi p Qper ator , ' >ANY ' 

The operator , ?-?-ANY , is evaluated as follows- The 
condition, A >ANY B, evaluates to be true if and only if the 
value of attribute A is greater than at least one value in 
the enumerated set B. The formal predicate logic definition 
foil ows : 



Vk (x e a <==> 3y <y e B j x > y)> ==> 

Vx (x e A <==> X > mi n ^B> ) 



EXAMPLE 7: If we wish to obtain supplier names for 

suppliers whose status is greater than 10, we 
may use the following query: 
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SELECT 



SNAME 



FROM S 

WHERE STATUS >A^4Y (10,20,30) 



The result relation is: 



SNAME 



Smi th 
B1 ake 
Clark 
Adams 



C- ALL-MEMBERSHIP OPERATIONS 

Like the comparison operator , ANY, the operator , ALL, is 
used in conjunction with the six standard relational 
operators. It also specifies variations on the set 

membership theme. 

1 - The Set Member shi p operator , ' =ALL " 

The operator , =ALL , is evaluated as follows. The 
condition, A =ALL B, eval uates to be true if and only if the 
value of attribute A is equal to every (each) value in the 
enumerated set B. The formal predicate logic definition 
foil ows : 

Vx (X £ A <==> 3y 6 B j x = y)) A 

Vy (y € B <==> 3” <x € A I X = y)) 



From this definition, it is apparent that the set B, whether 
manually enumerated or determined by the results of an inner 
SELECT, would contain only one value (or duplicates of that 
value). Therefore, since we can always use a condition of 
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the -form WHERE STATUS = 30, we shall not use the operator 
=hLL in farther discussion or examples- 

2. The Set tiembershi p Qper ator , ' ""=ALL ' 

The operator , ""=ALL , is i nterchangeabl e with the 
operator , t4QT_Ih4. The condition, A ""=ALL B, evaluates to be 
true if and only if the value of attribute A is not equal to 
every value in the enumerated set B, In other words, there 
is no value in the set B to which the value of attribute A 
is equal- The predicate logic definition of N0T_IN is 

repeated for clarity: 

V ^ <==>Vv C ^ 1 - ^ 

The query given in example 2 (with "■=ALL substituted for f'40T 
Ir4) is applicable- In subsequent examples involving set 
membership, we shall use NOT IN rather than "^=ALL- 

3. The Set Member sh i p operator , ' <=ALL ' 

The operator, <=ALL, is evaluated as follows- The 
condition, A <=ALL B, evaluates to be true if and only if 
the value of attribute A is less than or equal to every 
value in the enumerated set B- This implies that the value 
of attribute A is <= the minimum value in set B- The 
predicate logic definition follows: 

V>: (>< £ A <==>Vy (y £ B I X <= y) ) ==> 

\f X (x ^ A <==> X <= min ■CB>> 

Again, as in the case of the operator ANY, our degenerate 
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examples utilizing the operators <=ALL, >=ALL , <ALL, and 
>ALL will be presented with enumerated sets containing more 
than one member (even though, logically, only one member is 
necessary) . 



example 8: It we wish to obtain supplier names for 

suppliers 'whose status is not greater than 10, 
we may use the following query: 

SELECT SNAME 
FROM S 

WHERE STATUS OALL •: 10,20,30) 



The result relation is: 



SNAME 



Jones 



Note that the difference between the comparison operators 
ANY and ALL is readily apparent when we compare this example 
with example 4. In example 4, the operator , <=ANY, allows u 
to obtain supplier names for suppliers whose status is not 
larger than 30. The result relation in that example 
includes the names of all five suppliers. 

The Set Membership Operator , ' >=ALL ' 

The operator, >=ALL , is evaluated as follows. The 
condition, A >=ALL B, evaluates to be true if and only if 
the value of attribute A is greater than or equal to every 
value in the enumerated set B. This implies that the value 
of attribute A is greater than or equal to the maximum value 
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in set B 



he predicate logic definition follows: 



V>' (x E H <==>\/y (y E B I K >= y) > ==> 

V>: £ H <==> >= max ) 



EXAMPLE 9: If we wish to obtain supplier names for 

suppliers whose status is at least 30, we may 
use the following query: 



SELECT SNAME 
FROM S 

WHERE STATUS >=ALL (10,20,30) 



The result relation is: 



SNAME 



Blake 

Adams 



5- The Set Membershi p oper ator , ' < ALL ' 

The operator, <ALL, is evaluated as fallows. The 
condition, A <ALL B, evaluates to be true if and only if the 
value of attribute A is less than every value in the 
enumerated set B- The predicate logic definition follows: 



Vx € A <==> Yy (y G B | >; < y) ) ==> 
Vx <x £ A <==> X < min £B> ) 



EXAMPLE 10: if we v*ji sh to obtain supplier names for 

suppliers whose status is less than 10, we 
may use the following query: 
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SELECT 



SNAME 



FROM S 

WHERE STATUS <ALL (10,20,30) 



The result relation is: 



SWAME 



Note that this is the empty relation. There are no 

suppliers whose status is less than 10. 

6- The Set Membershi p Operator , ' >ALL ' 

The operator, >ALL , is evaluated as -follows- The 
condition, A >ALL B, evaluates to be true if and only if the 
value of attribute A is greater than every value in the 
enumerated set B. The predicate logic definition follows: 



V''< ^ A <==>Vy G S I X > y) ) ==> 

V (k G s <==> X > max CB> ) 



EXAMPLE 11: If we wish to obtain supplier names for 

suppliers whose status is greater than 30, we 
may use the following query: 



SELECT SNAME 
FROM S 

WHERE STATUS >ALL (10,20,30) 



The result relation is: 



SNAME 



As in example 10, this is the empty relation. There are no 
suppliers whose status is greater than 30. 
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EXPRESSING IN~MEMBERSHIP OPERATIONS IN ABDL 



D . 



In this and the following tv^o sections, we present ABDL 
translations for the examples given in sections A, B, and C, 
Each SQL example will be repeated , followed by the ABDL 
t ran si at i on - 



1 . The Set 


Membership Operator, 'IN' 


The SQL 


query presented as example 1 is 


SELECT 


S#, SNAME 


FROM 


S 


WHERE 


SNAME IN (Smi th , Jones) 



Uur proposed SQL interface would provide the following ABDL 
tr ansi at i on : 



RETRIEVE 


(((FILE = S) A (SNAME = Smith)) \/ 



((FILE = S) A (SNAME = Jones))) <S#,SNAME> 



One conjunction 


is created for each value in the enumerated 



set, containing an equality predicate. The ABDL request 
will have as many conjunctions as there are values in the 



set - 




2. The Set 


Membership operator , 'NOT IN' 


The SQL 


query presented as example 2 is 


SELECT 


S# 


FROM 


SP 


WHERE 


P# NOT IN (P3,P4) 
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ABDL translation is 



RETRIEVE ((FILE = SP) A (P# P3> A (P# P4) <3#> 

□ns predicate ai the -form (attribute value) is created 
-for each value in the enumerated set. The ABDL request will 
contain a single conjunction, which is the logical AND of 
these predicates. 

E. EXPRESSING ANY-MEMBERSHIP OPERATIONS IN ABDL 
1 - The Set Member shi p Qper ator , " =ANY ' 

As previously defined, =ANY is equivalent to IN and 
will not be included in our set of allowable SQL constructs. 
2. The Set liembershi p Operator , ' "^=ANY ' 

The SQL query presented as example 3 is 

SELECT S# 

FROM SP 

WHERE P# ^^=ANY (P1,P2> 

The ABDL translation is 





RETRIEVE 


( ( (FILE = SP) 


A 


(p# '^= PI ) > 


V' 






( (FILE = SP) 


A 


(P3 "■'= P2))) 


<s#> 


One 


conjunct! on 


is created for 


each value in 


the enumerated 


set , 


cont ai ni ng 


a predicate 


of 


the form 


(attribute = 



val Lie ) . 

- The Set Member sh i p Operator , ’ <=AMY ' 

The SQL query presented as example 4 is 



SELECT 



SNAME 



FROM S 

WHERE STATUS < = AN Y ( 1 0 , 20 , 30 ) 

The ABDL translation is 

RETRIEVE ((FILE =S) /\ (STATUS <= 30)) <SNAME> 

One predicate ot the form (attribute <= max_value) is 
created- The ABDL request will contain a single 

conjunction- Note that the SOL interface recognizes that 
the condition in the WHERE clause evaluates to true if and 
only if a supplier's status is less than or equal to at 
least one of the status values in the enumerated set 
(implying that that supplier's status is less than or equal 
to the maximum value in the set)- Therefore, only the 
maximum value, 30, is utilized in the ABDL translation. 

4. The Set Membershi p Operator , ' >=ANY ' 

The SQL query presented as example 5 is 

SELECT SNAME 
FROM S 

WHERE STATUS >=ANY (10,20,30) 

The ABDL translation is 

RETRIEVE ((FILE = S) A (STATUS >= 10)) < SNAME > 

One predicate of the form (attribute >= min_value) is 

created. The ABDL request will contain a single 
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conjunction. As in the ■*<=ANY* case, only one value ot the 
enumerated set in the WHERE clause is utilized in the ABDL 
transl at i on - In this case, the minimum value, 10, is 



Liti 1 i zed. 




5- The Set 


Membership Operator , '<ANV'' 


The SQL 


query presented as example 6 is 


SELECT 


SNAME 


FROM 


S 


WHERE 


STATUS CANY (10,20,30) 



The ABDL translation is 

RETRIEVE ((FILE = S> A (STATUS < 30)) <SNAME> 



One predicate 


of the form (attribute < max_vaiue) is 


created. The 

con junct i on - 


ABDL request will contain a single 


6. The Set 


Membership Operator , ' >ANY ' 


The SQL 


query presented as example 7 is 


SELECT 


BNAME 


FROM 


S 


WHERE 


STATUS >ANY (10,20,30) 



The ABDL translation is 

RETRIEVE ((FILE =S> A (STATUS > 10) ) <SNAHE> 
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One predicate o-f the -form (attribute > min_value) is 
created. The ABDL request will contain a single 

conjunct! on . 

F. EXPRESSING ALL-MEMBERSHIP OPERATIONS IN ABDL 

1 - The Set Member shi p Operator , " =ALL " 

As previously de-fined, use o-f the operator , =ALL , is 
equivalent to using the standard equality operator , =. We 

will, therefore, not include it in our set of allowable SQL 
constructs . 

2- The Set Member shi p Qper ator , ' "^=ALL ' 

As previously defined, ''*'=ALL is equivalent to 

NOT_IN and v^i 1 1 not be included in our set of allowable SQL 
constructs. 

3- The Set Member shi p Operator , " <=ALL ' 

The SQL query presented as example 8 is 

SELECT SNAME 
FROM S 

WHERE STATUS <=ALL (10,20,30) 

The ABDL translation is 

RETRIEVE ((FILE = S) A (STATUS <= 10)) < SNAME > 

One predicate of the form (attribute <= min_value) is 

created- The ABDL request will contain a single 

conjunction. As in the '<=ANY' case, the translator in our 
SQL interface utilizes only one value from the enumerated 
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set- Note that in this case, the minimum value, 10, is 
chosen, whereas, in the '<=ANY' case the maximum value, 3u - 



is chosen- 




4- The Set 


Membershi p Operator , ' >=ALL ' 


The SQL 


query presented as example 9 is 


SELECT 


SNAME 


FROM 


S 


WHERE 


STATUS >=ALL ( 1 0 , 20 - 30 ) 



The ABDL translation is 

RETRIEVE ((FILE = S> A (STATUS >= 30)) <SNAME> 

One predicate o+ the form (attribute >= max_value) is 
created- The ABDL request will contain a single 

conjunction- As in the ' >=ANY ' case, only one value of the 
enumerated set is utilized- In this case, the maximum 
value, 30, is utilized in the equivalent RETRIEVE construct - 
We recal 1 that the minimum value, 10, was utilized in the 



'>=ANY' case. 




5. The Set 


Membership Operator , '<ALL' 


The SQL 


query presented as example lO is 


SELECT 


SNAME 


FROM 


S 


WHERE 


STATUS < ALL (10,20,30) 



The ABDL translation is 
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RETRIEVE ((FILE = S) / (STATUS < 10)) <SNAr1E> 

One predicate o-f the -form (attribute < min_vaiue) ib 

created. The ABDL request will contain a single 

con junct i on . 

6- The Set Member shi p Operator , " >ALL ' 

The SQL query presented as eKample 11 is 

SELECT SWAME 
FROM S 

WHERE STATUS >ALL (10,20,30) 

The ABDL translation is 

RETRIEVE ((FILE = S) A (STATUS > 30) > <SNAME> 

One predicate of the form (attribute maK_value) is 

created. The ABDL request will contain a single 

con junct i on - 
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V. SELECTIONS WITH SET MEMBERSHIP OPE RATIONS ON 
MULTIPLE RELATIONS 

In the preceding chapter, we have described SQL SELECT 
queries which utilize the comparison operators, IN, ANY, and 
ALL in the WHERE clause. These are simple, si ngl e— rel at i on 
queries in which the associated sets are enumerated. We now 
discuss the nested SQL SELECT queries (or nested mapping) in 
which the result of one mapping is used in the WHERE clause 
of another mapping. In other words, the membership of the 
set following IN, ANY, or ALL in one SELECT operation is 
determined by the result set of another SELECT. We will 
describe the operation of two— level, three— level and n— level 
nested SELECTS in Sections A, B, and C, respectively. In 
Section D, we show how the nested SQL SELECT is translated 
into a series of ABDL RETRIEVES. 

A. NESTED SELECTIONS WITH TWO RELATIONS 

As previously stated, in a nested SQL SELECT, the 
results of one SELECT operation are used in the WHERE clause 
of another SELECT operation. We view the former SELECT as 
the inner (level of) SELECT, and the latter as the outer 
(level of) SELECT. Figure 8 depicts an example of a two- 
level nested SELECT operation- This particular example is 
chosen for its similarity to one of our examples in Chapter 
IV (i.e.. Example 6) which utilizes the operator , <ANY, in 
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conjunction with e. manually enumerated set. In the 
degenerate case presented in that example, the operator , 
<ANY, appeared to be of marginal usefulness. The usefulness 
of this and similar operators (e.g. , <=ANY, >=ALL) in the 
nested SELECT, will now become apparent. 

Both our current example in Figure 8, and Example 6 of 
Chapter IV result in a set of supplier numbers for suppliers 
with status value less than the current maximum status value 
in the S table. In our degenerate example, we must know 
(i.e., enumerate) that that value is 30. In our present 
example, we allow an inner SELECT to obtain the status value 
for each supplier number in the S table. By employing an 
inner level of SELECT, we are free from enumerating the 
val ues. 



Outer 

SELECT 



Inner 1 
SELECT 
Figure 8. 



SELECT 

FROM 

WHERE 



S# 

S 

STATUS CANY 
(SELECT STATUS 
FROM S) 



A Two— Level Nested SELECT 



Processing of the two-level nested SELECT in Figure 8 
proceeds as follows. First, the inner SELECT retrieves all 
status values in the S table. The result of this SELECT is 
the set (with duplicates) of status values <20,10,30,20,30. 
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The outer SELECT then eeiecte supplier numbers FROM table S 
WHERE the status value is less than at least one o-f the 
values in the above result set. The result relation is 

S# 

51 

52 

S4 

B- NESTED SELECTIONS WITH THREE RELATIONS 

We now describe a three— level nested SELECT. We present 
an example which demonstrates the use-fulness of the 
set /compar i son operator IN, and of multi-level SELECTS in 
general - In the course of providing the requested data, 
this three— level SELECT chooses data from each of the three 
tables which comprise our sample database- The request is 
to get supplier names for suppliers who supply at least one 
red part- The query is presented in Figure 9- 



Qutermost 

SELECT 



SELECT 

FROM 

WHERE 



I nner 
SELECT 



SNAME 

S 

S# IN 
<SELECT 
FROM 
WHERE 



Innermost 

SELECT 



S# 

SP 

P# IN 
(SELECT 
FROM 
WHERE 



Figure 9. A Three— Level Nested 



P# 

P 

COLOR 

SELECT 



' RED ' ) ) 
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Processing of the query 



in Figure 9 proceeds 



as 



foil cws - 

Step 1: The innermost SELECT retrieves part numbers 

(P#) from the parts relation (P) where the color 
of the parts is red. The result of this SELECT 
is the set of part numbers fP 1 , P4 , P61- . 

Step 2: The next SELECT retrieves supplier numbers (S#) 

from the shipments relation (SP) where P#s are 
in the result set of step 1. The result of this 
SELECT is the set of supplier numbers fSl,S2,S4>. 



Step 3: 



The outermost SELECT 
(SNAME) from the supp 
S#s are in the result 
relation passed to the 



retrieves supplier 
liers relation (S) 
set of step 2. The 
user i s 



SNAME 



Smi th 
Jone« 
C 1 ar k 



names 
where 
resul t 



C. NESTED SELECTIONS WITH N RELATIONS 

Although it seems unlikely that many users would utilize 
a nested SELECT of more than 2 or 3 levels, the subqueries 
can be nested to any depth. The form of an n— level nested 
SELECT is shown in Figure 10. 

The SET_0PR in Figure 10 refers to the various forms of 
our comparison operators IN, ANY, and ALL. In the next 
section, we describe the translation of nested SELECTS to a 
series of ABDL RETRIEVES. Therefore, it is important that 
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SELECT s-el_expr_l ist 
FROM rei at i on_name_l 

WHERE attri bute_namel SET_OPR 
(SELECT attri bute__namei 
FROM rel at i an_name_2 
WHERE attribute name2 SET GPR 



level i or 
} outermost 
SELECT 



level 2 or 
> inner 
SELECT 



(SELECT attr i bute__name (n-*l ) 
FROM rel at i on_name_n 
WHERE condition) . . . ) 



level n or 

! i nnermost 
SELECT 



Figure 10. An N“Level Nested SELECT 



we note the Tollowing information as succinctly stated in 
CRef. 11 . 



'’The nth 1 evel is the i nner most 
level is the outermost SELECT. 

i nner SELECT, i.e., a SELECT 1 ower than level j. , 
a single attribute name, which is the same 



SELECT. 

The sel __expr__l i st 

i 



The 1st 
of each 
contains 
as the 



attribute name used in the qual i f i cat i on of the next- 
higher level SELECT. The relation names at any two levels 
may be the same. ” 



D. TRANSLATING NESTED SELECTIONS TO A SERIES OF ABDL 
RETRIEVALS 

As shown by Macy CRef. 8D , there exists a 
strai ghtf orward mapping between the SQL SELECT operation and 
the ABDL RETRIEVE operation. We can, therefore, simulate 
the nested SELECT with a series of RETRIEVES, each 
succeeding operation using the results of the previous one. 
Thus, referring to our three— level example of Section B, the 



hBDL equivalent ot the innermost SELECT is 



RETRIEVE ((FILE = P) A (COLOR = 'RED')) <P#> 

The resulting set o-f part numbers *CP1,P4,P6> is then used in 



the next ABDL 


oper at i on 


as 


f ol 1 ows: 






RETRIEVE 


( ( (FILE = 


SP) 


A 


( P# = 


PI ) ) 


V 




( (FILE = 


SP) 


A 


(P# = 


P4) ) 


V 




( (FILE = 


SP) 


A 


(P# = 


P6) ) ) 


<S# 



The last retrieve ( cor r espondi ng to the outermost SELECT in 
our example) then uses the resulting set o-f supplier numbers 
CS1,S2,S4> as follows: 



RETRIEVE (((FILE = S) 


A 


(S# = SI ) ) 


V 


( (FILE = S) 


A 


(S# = S2) ) 


V 


( (FILE = S) 


A 


(S# = S4) ) ) 


< SNAME 



It is intended that the operation of our SQL interface be 
transparent to the SOL user. Therefore, the resulting 
values of the attribute SNANE (Smi th , Jones , Cl ark ) are 
returned to the user in the form of the result relation 
previously described for our three— level nested SELECT 
example of section B- 

We have now demonstrated the operation of data 
retrievals involving the nested SELECT construct- These 
nested operations may include use of the various forms of 
IN, ANY, and ALL. The sequence of actions necessary to 
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translate the nested SQL SELECT to a serie 



of ABDL 



RETRIEVES has been described. In the next chapter 
present our proposals for the implementation ot 
t ransl at i one . 



, we 
these 



67 



VI - 



IMPLEMENTING NESTED SELECTIONS 



The logical process by v^hich a nested SQL SELECT is 
translated to a series o-f ABDL RETRIEVES has been described- 
It is clear that each SELECT level, -From the innermost to 
the outermost, must be translated to an ABDL RETRIEVE, 
Then. each RETRIEVE is processed in turn, with each 
succeeding operation utilizing the results o-F the previous 
RETRIEVE in the QUERY part- In Section A of this chapter , we 
present the algorithms for building the ABDL QUERY- In 
Section B, a simple iterative structure for controlling the 
execution of n — level nested SELECTS is provided- Final Iv- 
in Section C- the overall software structure of our SQL 
interface will be proposed- Note that, as we continue our 
bottom-up investigation and include additional SQL 
operations in our set of allowable constructs- the 
functionality of this structure may be augmented- However, 
it is evtpected that the software structure will remain 
i ntac t - 

A- ALGORITHMS FOR BUILDING THE ABDL QUERY 

We recal 1 that the Query part of ABDL RETRIEVES (DELETE 
and UPDATE, as well) is written in a disjunctive normal 
form- A QUERY may be a single conjunction or it may be a 
disjunction of conjunctions- The number of conjunctions 
generated in the translation of nested SELECTS utilizing the 
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various forms of IN, ANY, and ALL has been noted in Sections 
D, E, and F of Chapter IV- Figure 11 summarizes this 
information. The figure also specifies the relational 
operators involved, as well as the source of the values to 
be used in each conjunction. 



Set Opr # Conjun 


ctions Rel Opr 


Value Source 




IN 


n 


= 


result set 




NOT IN 


1 




result set 




'^•=ANY 


n 


— 


result set 




<=ANY 


1 


< = 


max ( r esul t 


set) 


>=ANY 


1 




min (r esul t 


set ) 


< ANY 


1 


<*] 


max (r esul t 


set > 


>ANY 


1 


> 


min (r esul t 


set > 


< =ALL 


1 


< = 


mi n ( r esul t 


set ) 


>=ALL 


1 


>= 


max (r esul t 


set ) 


<ALL 


1 


< 


mi n (r esul t 


set ) 


>ALL 


1 


> 


max (resul t 


set ) 


Fi gur e 


1 i - 


Summary of Nested SELECT 
Set Comparison Operators 




From Figure 


11 , 


it is clear that our 


transl ator 


must 


perform a multi 


way 


select! on depend! ng 


upon which 


set 



comparison operator is utilized at each SELECT level. We 
describe an appropriate algorithm in Subsection 1. It can 
also be seen that, in the case of the operators IN and 
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, a number of conjunctions are generated , one for each 
value in the result set of the previous operation- In 
Subsection 2, we present an n-con j unct i on algorithm to 
handle these two cases. h4ote that in all remaining cases, a 
single conjunction is generated. The 1 — con j uncti on 
algorithm is presented in Subsection 3. 

i . The Quer y-Constructor Subroutine 

As noted above, the top-level translator portion of 
our SQL interface must determine from the set comparison 
operator the proper algorithm for constructing the QUERY 
part of the resultant ABDL request- This can be handled bv' 
a multi-way selection or CASE construct, as shown in the 
Query— Const ructor Algorithm in Figure 12. The parameters 
passed to Quer y_Construct or are Quer y_Temp 1 ate (a 
conjunction, described in Subsection 2, constructed to 
facilitate the i ncor por at i on of succeeding result sets), the 
Result_Set of the previous request, and the appropriate 
Set_Opr from Figure 11. 

In each alternative of the CASE statement of Figure 
12, the correct relational operator is chosen, and either 
the n— con j unct i on or the 1— con juncti on subroutine is called. 
The parameters provided for each subroutine call are the 
relational operator and the result set of the previous 
operation, or the maximum/minimum value of the result set- 
As previously discussed, when ANY and ALL are used with 
these relational operators, only one value of the result set 
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Subrout i ne Quer y^Constr uctor ( Query _T empi ate , Resui t _Set ^ 

Set _Opr ) 

CASE Set_Opr OF 



IN: 



>=ANY; 



<ANY: 



>ANY: 



:=ALL; 



Rei_Opr < — '=' 

cai 1 N_con juncti on (Query_Tefnp i ate , Resui t_Set , 

Rel _Opr ) ; 



NOT IN: Rel__Opr < — ' 

call One_con juncti on (Query_Tempi ate , Resui t_Set , 

Rei _Opr ) ; 

^=ANY: Rel_Opr < — 

cal 1 N_con juncti on ( Query__Temp 1 ate, Resui t_Set , 

Rel _Opr ) ; 

< =ANY : Rel _Qpr < — ' < = ' 

cal 1 One^con juncti on ( Quer y_Temp 1 at e , 

max (Resui t_Set) ,Rei_Opr) ; 



Rel_Opr < — ' >= ' 

cal 1 One_con juncti on ( Query_Templ ate , 

mi n ( Resui t_Set ) ,Rel_Opr) ; 

Rel_Opr < — '<' 

call One_con juncti on ( Quer y_Templ ate , 

max (Resui t_Set) ,Rei_Opr) ; 

Rei_Dpr < — '>' 

cal 1 On e_c on juncti on ( Quer y_T emp 1 ate , 

min (Resui t _Set ) , Rei _Opr ) ; 

Rel_Opr < — '<=' 

cai 1 One_con juncti on (Query_Templ ate, 

mi n ( Resui t_Set ) , Rei __Opr ) ; 



>=ALL: Rel_Opr < — ' >= " 

cal 1 Qne_con juncti on (Query_Tempi ate, 

max (Resui t_Set) ,Rel_Opr> ; 

CALL: Rel_Opr < — '<' 

cai 1 One_con juncti on (Query_Templ ate, 

mi n ( Resui t_Set ) , Rel _Qpr > ; 

>ALL : Rel _Qpr < — ' > ' 

call On e_c on juncti on ( Quer y_T empl ate , 

max (Resui t_Set) ,Rel_Opr) ; 

END CASE 

END Quer y_Con struct or 

Figure 12- The Query_Constructor Subroutine 
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is utilized in the translation- Depending upon which rorm 
o-F the set comparison operator is used, the selected value 
will be either the maximum or the minimum value in the 
result set- There-fore- a cal 1 to a standard Max or Min 
function, as appropriate, must be made prior to sending the 
resultant single value to the 1 —con junct i on subroutine- It 
should be noted that the 1 -con junct i on subroutine is called 
in the case of the operator NOT IN- However, there is no 
need to utilize a Max/Min function- We also note that a 
call to Max/Min is never needed prior to a call to the n— 
conjunction subroutine- 

2- The N— Con junct i on Subrout i ne 

In the case of the set operators IN and ''"=ANY - the 
above Query— Construe tor subroutine will call the n— 
conjunction subroutine- In the process of translating 
nested SELECTS which utilize these operators, one 
conjunction of the form 

((FILE = Relname) A (Attrname Rel _opr Value)) 

will be generated for each value in the result set- These 
conjunctions are ORed to form a disjunction of con junct i ons , 
as explained in Chapter IV, Sections D and E- An 
algorithmic r epr esen t at i on of the n— con j unc t i on generation 
subroutine is provided in Figure 13- 

The template, defined in Figure 13, is provided by 
the top— level translator as it translates each SELECT level 
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to an ABDL RETRIEVE- Vai ue_ot _Tempi ate is the only variable 
which requires substitution. For the innermost (nth level) 
SELECT or a nested SELECT request, the equivalent RETRIEVE 
can be constructed completely- However, at translation 
time, the values to be used in the query portion ot the 



Subrout i ne N_con juncti on (Ouery_Tempi ate , Rel _opr ) 



/ 


Query_T emp 1 ate; 




* / 


/* 


is ((FILE = Relname) 


A (Attrname Rei_opr Value)) 




/* 


Query: 






/* 


is Quer y_Templ ate V 


Query_Template V - - . 






V 


Quer y_T empl ate 


*/ 


/* 








/* 


For every value in the 


Resul t _set 




/* 


generate one conjunction using Template 


*/ 


/* 


then OR— concatenate into Query- 




Rel 


_opr _of _Templ ate < — Rel 


_opr 





i_f Result_set is NOT EMPTY 
then 

Val ue_of __Temp 1 ate < — 1st value -from Result_set 
Query < — Quer y_Templ ate /* Relname Attrname */ 

/* -fill ed in 

whi 1 e more values in Result_set do 

Value__of _Template < — next value from Result_set 
Query < — Query II ' V ' II Template 
end whi 1 e 
el se 

Query < — ' ' /* Query is nil */ 

END N_c on June t i on 

Figure 13- The N— con June ti on Subroutine 



remaining n— 1 
is provided 
the missing 



SELECTS are unknown- Therefore, the template 
to the N— con junct i on generator which fills in 
values and constructs the QUERY part of each 



RETRIEVE- 
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The 1 —Con j unct i on Sab rout i ne 



In the case o-f the operator NOT IN and ai 1 ot the 
ANY/ALL operators containing <=, >= , <, or >, the CASE 
statement causes a call to the 1 — con junct i on subroutine. As 
described in Chapter IV, one predicate o-f the -form 
(Attribute Rei_opr Value) is generated for each value in the 
result set. These predicates are then ANDed to form a 
single conjunction- An algorithmic repr esentat i on of the 1— 
conjunction subroutine is provided in Figure 14. 



Subroutine One_con junct i on (Query_Templ ate , Resul t_set , 

Rel _opr ) 



/♦ Duery_Templ ate: 

/★ is ((FILE = Relname) A (Attrname Rel_opr Value)) */ 
/* Predicate: */ 

/* is (Attrname Rel_opr Value) -^/ 

/* Querv': 

/■«• is Ouery_Templ at e A Predicate A ... 

/* A Predicate 

Strip right paren from Query_Temp 1 ate 
Rel _opr_of _Templ ate < — Rel_opr 

if Resul t_set is NOT EMPTY 
then 

Val ue_of _Templ ate < — 1st value from Resul t_set 
Query < — Query__Templ ate 

whi 1 e more values in Resul t_set d^ 

Val ue_of_Predi cate < — next value from Resul t_set 
Query < — Query S ! 'A ' ! ! Predicate 

end whi 1 e 
el se 

Query < — ' ' /* Query is nil */ 

Query_Templ ate < — Query_Templ ate II ') ' 

Figure 14. The 1 —con junct i on Subroutine 
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Note, in Figure i4, that the template provided to the 1- 
c on junction subroutine is identical to that used in the N— 
conjunction subroutine. An additional data structure, 

Predicate is de-fined as (Attrname Rel_opr Value). The use 
o-F this additional 'template' allows us to extend the single 
con junct i on , 

((FILE = Relname) A (Attrname Rel_opr Value)) 
to the mul tipi e— pr edi cate si nql e conjunction, 

((FILE = Relname) A (Attrname Rel_opr Value) A - - . 

A (Attrname Rel _opr Value)) 

The number o-f predicates generated is determined by the 
number of values in the Result_set. 

B, AN ITERATIVE STRUCTURE FOR CONTROLLING THE EXECUTION 
OF N-LEVEL SELECTIONS 

In the previous section, we have presented algorithms 
for building the QUERY part of each ABDL RETRIEVE generated 
in the translation of a nested SQL SELECT. We now consider 
the process of controlling the execution of this process. An 
algorithmic r epr esentat i on of a simple structure for the 
control of this iterative process is provided in Figure 15. 

This N_1 evel _Sel ect subroutine is called by the Top-level 
process of the interface (described in Section C) - The 
parameters passed include a series of ABDL RETRIEVE requests 
(in the form of a request stack), and the number, n, of such 
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requests- We recall, from Chapter V, that the innermost 
SELECT level is viewed as the nth~level- Request_Stack has 
the ABDL translation of the nth— level SELECT on top. The 
Ist-level SELECT is on the bottom. The stack is formed in 
this order because the nth— level request is the only request 
containing a fully formed query_part (as described in 
Chapter V). Each of the other n— 1 requests requires the 
Result_set of the immediately preceding request before it 
can be sent to MDBS for processing. 



Subrout i ne N_1 evel __3el ect ( Request_Stac k , n ) 



/* Request_Stac k has the ABDL translation of the */ 

/* nth— level SELECT on top. The 1st— level SELECT 
/* IS on the bottom. Each request in the Stack is 
/* composed of the reserved word RETRIEVE, Target_List, */ 
/* Set_Qpr, and Query_Part. The Query_Part of the i^/ 

/* nth — level SELECT is fully formed. The Duery__Part 
/* of the n-1 — > let-level SELECTS is a query template 
/* having the form *■/ 

/* ((FILE = Fielname) A (Attrname Rel_opr Value)) */ 

/* with a blank in the 'Value' position. -^/ 



Current_Request < — Pop ( Request _St ac k ) 

Send ( Cur rent _Request ) 

Reci eve (Resul t_Set ) 

f or i < — 1 to n— 1 d^ 

Curr ent__Request < — Pop ( Request _Stac k ) 

Cal 1 Query_Constructor ( Query _Part , Resul t_Set , Set_Opr ) 
Send (Curr ent_Request ) 

Recei ve (Resul t_Set ) 
end f or 

Di spl ay (Resul t_Set ) 
end N level Sel ect 



Figure 15. 



An Iterative Process for Controlling 
the execution of N-1 evel SELECTS 
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The operation of the N_1 evei _3ei ec t subroutine is as 
follows. The nth~level request is popped off the top of 
Request_Stack and becomes the Cur r ent_Request This 
Current Request is forv-^arded to MDBS through the Send 
function. Upon completion of processing, the Result_set is 
obtained through the Recei ve function. The remaining n— 1 
requests are popped off the stack and processed in order . 
The nth and succeeding result sets are incorporated into 
each request through a call to Query—Const ruct or (described 
in Section A). The Send and Receive functions are used on 
each iteration to route request /resul t traffic between 
N_i evel _Sel ect and MDBS- When the last request has 
completed processing, the final result set is provided to 
the user through a call to the Pi spl ay subroutine- Display 
presents the results of the original nested SQL SELECT as a 
resul t rel at i on (this is the format expected by a SQL user) „ 



C. PROPOSED SOFTWARE STRUCTURE 

In this section, we present a software structure for the 
implementation of nested selections in our proposed SQL 
interface. In fact, all of the translations heretofore 
introduced in this thesis and in Macy CRef. , are 
supported by this structure- Therefore, allowing for 
possible modi f i cat i ons required to support additional 
multiple and si ngl e— rel at i on SQL operations, the software 
structure depicted in Figure 16 represents the overal 1 
software structure of the SQL interface. 
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As depictsd in Figure 16, the SQL interface is comprised 
of a single top-level process with multiple subroutines and 
functions. The top-level process is called SQLI (SQL 
Interf ace) . We have described the N level Select subroutine 




Figure 16. The Proposed Software Structure 



group- We discuss 


the 


r emai n i ng 


subroutines as we explain 


the functionality 


of 


SQLI . 


An 


algorithm for SQLI is 


presented in Figure 


17. 









78 




The operation of 5QLI is an follows. Once a session is 
initiated from the user terminal , the actions depicted in 
ALGORITHM 5QLI are repeated until session termination- The 
SQL query to be translated into the equivalent ABDL 
construct is obtained through a call to the subroutine 
Get_SQL_Query . This subroutine polls the user terminal for 



ALGORITHM SQL I 
Repeat 

CALL Get _SQL_Quer y (Query) 

CALL SQLT ( Query , Request _Stack , N , Err or s ) 
i f N = O then Syntax Errors */ 

CALL Di splay (Query ) 

CALL Di splay (Errors) 

el se i f N = 1 then /* Single Request */ 

Send (Pop < Request _Stack ) ) 

Recei ve (Resui t_Set ) 

CALL Di sp 1 ay (Resui t _Set ) 
el se . /* h4“level Request */ 

CALL N_1 evel _Sel ect ( Request _Stack ,^4) 
end i f 

End_of _sessi on? 
unt i 1 end_of _sessi on 
end ALGORITHM SQL I 

Figure 17. The Top-level Process of the Interface, SQLI 



input- Note that when a query is obtained, the polling 
stops until the result relation is received by the user (or 
syntax errors are displayed for the user). This restriction 
is placed in order to preclude the complexity of processing 
more than one request at a time. (We assume that several 
user terminals have access to a copy of SQLI, and that each 
user makes a request and waits for a result before making 
another request). 
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The query obtained by the call to Get_SGlL_Quer y is 
passed as a parameter in a call to the SQL Translator 
(3QLT) subroutine. SQLT parses the query, recognizes the 
query— type, checks Tor syntax errors, and translates the SQL 
query to the appropriate ABDL request. IT there are no 
S'/ntax errors, SQLT places the translated requests in a 
stack and returns this Request_St ack , along v-^ith the number, 
N, oT requests in the stack. In the case oT simple, single- 
relation operations, Request_Stack contains one request. In 
the case oT a nested selection, SQLT Tirst parses and 
translates the outermost SELECT placing the resultant 
RETRIEVE request on the stack. As previously discussed, the 
request contains a query— temp 1 at e . (Recall that only the 
nth— level- or innermost, request is Tully Tormed). IT there 
are syntax errors, SQLT returns a value oT zero Tor N. The 
errors are also returned. 

IT the number oT requests in Request_Stac k is zero (N = 
O) , then SQLT has detected syntax errors- In this case, 
SOLI makes two calls to the Display subroutine in order to 
provide the user a display oT the query and oT the errors 
detected- IT the number oT requests in Request _Stack is one 
(N = 1> , then the single request is popped oTT the stack and 
Torwarded, via the Send Tunction, to MDBS Tor processing. 
The Result_set is obtained through the Recei ve Tunction. 
The result relation is provided to the user through a cal 1 
to the Di spl ay subroutine- IT the number oT requests in 
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Requsst^Stack is greater than one, then N_i evei _Sei ect is 
called. The subsequent processing is explained in Section 

B. 

As previous!’/ discussed, we propose that the SQL 
interface be implemented such that SQLI and its subroutines 
are resident on a host computer- This precludes the need to 
place an additional workload on the MDBS Controller. In 
effect, MDBS is "unaware” that the user is making database 
requests in SQL, and the user need only know what 
information is desired and how to form the request in the 
syntax of SQL- The logical structure of the system is 
depicted in Figure 18- 
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I 

I 
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in 

host 

computer 



MDBS 



i n the 

backends and 
their controller 



Figure 18- The Logical Structure of the System 



81 



VII. ADDITIONAL 5QL-TQ-ABDL TRANSLATIONS 



We have described si nql e-r el at i on set membership and 
mal ti pi e—rel at i on nested SQL SELECT operations. For each 
SQL operation, we have developed the appropriate ABDL 
translation- In Chapter VI, we have proposed a software 
structure to facilitate the implementation of these 
tr ansi at i ons , in addition to the simple, si ng i e— r el at i on 
translations which Macy CF’ef. 81 has provided. In this 
chapter, we investigate other selected si ngl e-r el at i on and 
mul ti pi e— rei at i on SQL operations. Inclusion of these highly 
desirable options in the SQL set operations supported by the 
interface further demonstrates the power of ABDL to support 
relational operations. 

As in previous chapters, the approach of this chapter is 
to describe each SQL operation and then determine which ABDL 
constructs can be used to support the operation. As each 
translation is developed, we show graphically, 
algorithmically, and through text how the software structure 
of the interface (described in Chapter VI) must evolve in 
order to accomodate the additional operations. The single- 
relation operations are presented in Section A, and the 
mul t i p 1 e— r el at i on operations are presented in Section B. In 
Section C, we present the modified software structure of the 
SQL interface. 
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A- 



SELECTED SINGLE-RELATION OPERATIONS 



The si ngl e-rel at i on operations selected for discussion 
in this section include: updating multiple attributes in a 
single record; retrieving groups of attributes which satisfy 
a group condition; retrieving computed values; providing 
format options; retrieving ordered attributes (SORT); and 
eliminating duplicates (PROJECTION)- These operations are 
commonly supported in commercial relational database systems 
utilizing the SQL language- A SQL—trained user of the 
interface proposed in this thesis would expect to be able to 
utilize familiar SQL constructs to perform these operations- 
We address the SQL-TO-ABDL translations in the following 
sub sec ti ons- 

1 - Updat i nq Mul tipi e— Attr i butes 

All data languages provide a data update capability- 
Of interest here is the SQL construct for update- This 
construct allows the user to change the values of any number 
of attributes stored in the record by issuing a single 
query- This capability is both convenient and efficient- 
The following example depicts the updating of multiple- 
attributes (fields) in a single record- If we wish to 
change the color of part P2 to yellow- increase its weight 
by 5, and set its city to Normandy, we may use the following 
SQL query: 
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UPDATE 



P 



SET COLOR = 'Yellow', 

WEIGHT = WEIGHT + 5, 
CITY = 'Normandy' 





WHERE P# 


= 'P2 ' 






In this 


example, we 


are updating 


the 


attributes COLOR, 


WEIGHT, 


and CITY in a 


single record 


wi th 


primary key, P2- 



The record is contained in the Parts (P) relation- Note 
that any re-ference to an attribute on the right— hand side o-f 
an equals sign refers to the value of that attribute pr i or 
to updating- 

In studying the SQL example above, we note that 
there are three cases to consider depending on the 
attributes listed in the SET and WHERE clauses. We refer to 
these as case— O, case— 1 , and case— 2 updates. To facilitate 
the following explanation, let S be the set of distinct 
attribute names listed in the SET clause, and W be the set 
of distinct attribute names listed in the WHERE clause. In 
case— O updates (e.g. , the above example) - no attribute is 
listed in both the SET and WHERE clauses (i.e., S O W = O) . 
In case— 1 updates , one attribute is listed in both clauses 
(i.e., cardinality(SOW) = 1). In case— 2 updates mul ti pi e 
attributes are listed in both clauses 
(i.e., cardi nal i ty (S ^^W) > 1). A case- 1 modification of 
our example is as follows: 



84 



UPDATE P 

SET COLOR = 'Yeiiow', 

WEIGHT = WEIGHT + 5, 

CITY = 'Normandy' 

WHERE <P# = 'P2') AND (CITY = 'Paris ) 

Note, CITY is in both S and W, and the cardinality of 

(S O W) is i. A case— 2 modification of our original 

example is as follows: 

UPDATE P 

SET COLOR = 'Yellow', 

WEIGHT = WEIGHT + 5, 

CITY = 'Normandy' 

WHERE (P# = 'P2') AND (CITY = 'Paris') 

AND (COLOR = 'GREEN') 

Note, CITY and COLOR are in both S and W, and 

cardi nal i ty (S O W) >1- The SQL-to-ABDL translations of the 
three cases of multiple-attribute update are described in 
the following subsection. 

a. The translation to ABDL 

ABDL does not provide a single-request construct 
which updates more than one attribute in a record. We must 
translate the SQL UPDATE into multiple ABDL UPDATES. Case-0 
SQL UPDATE queries can be translated directly to multiple 
ABDL UPDATE requests. The order in which these requests are 
processed is immaterial. The case— Q example above 
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translates to the following three independent ABDL UPDATE 



requests : 



UPDATE 


(FILE 


= P) 


A 


(P# = P2) ) 


(COLOR = 


■ Yel 1 ow) 


UPDATE 


( (FILE 


= P) 


A 


(P# = P2) ) 


(WEIGHT 


= WEIGHT + 5) 


UPDATE 


( (FILE 


= P) 


A 


(P# = P2) ) 


(CITY = 


Nor mandy ) 



Our case-1 example translates to the same three 
UPDATE requests, however, the presence of the CITY attribute 
in both the WHERE and SET clauses effects the structure of 
the translation. The order of request processing now 
becomes important. For example, if CITY is updated first, 
the condition ( (P# = ' P2 ' ) AND (CITY = 'Paris')) is no 

longer satisfied when a subsequent attempt is made to 
process the COLOR and WEIGHT UPDATE requests. ABDL provides 
a construct called a Tr ansact 1 on which specifies the order 
in which a series of requests must be processed. Therefore, 
case— 1 translation becomes 

BEGIN Transact! on 



UPDATE 


( (FILE = P) 


/\ 


(P# = P2)) 


(COLOR = Yellow) 


UPDATE 


( (FILE = P) 


A 


(P# = P2) ) 


(WEIGHT = WEIGHT + 5) 


UPDATE 


( (FILE = P) 


A 


( P# = P2 ) ) 


(CITY = Normandy) 



END Transaction 

Requests within a transaction are processed in the same 
order as they are specified. Therefore, we can obtain a 
correct result- 
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The case-2 example also translates to a series 



of three ABDL requests. However, the translation is more 
complex. In this case, multiple attributes specified in the 
WHERE clause are also listed in the SET clause. When the 
first of these attributes is updated, all subsequent 
attempts to update the remaining attributes will fail. 
Since the WHERE condition is no longer satisfiabie, the 
record can not be found. The following sequence of ABDL 

requests accomplishes the requested update. (Note that the 
ABDL UPDATE construct is not used). 

RETRIEVE ((FILE = P) A (P# = P2) ) <P# , PNAME , COLOR , WE IGHT , 

CITY> 

DELETE ((FILE = P) A (P# = P2) A (PNAME = Bolt) A 
(COLOR = Green) A (WEIGHT = 17) A 
(CITY = Paris) ) 

INSERT (<FILE = P>,<P# = P2>,<PNAME = Bolt>, 

<COLOR = Yel low>,<WEIGHT = 22>,<CITY = Wormandy>) 

b. A proposed Software Structure 

In order to implement mul t i pi e— attr i bute 

updates, we must augment the f unct i onal i ty of the software 
structure (SQL I) which we have developed in Chapter VI. We 
specify an additional parameter. Request Type , to be 
returned by SQLT. When the value of Request__Type is 

' CaseO_update ' , the subroutine CaseO_update is called. In 
this case, the multiple ABDL RETRIEVE requests are simply 
removed from Request_Stack and forwarded to MDBS for 
processing. As previously stated, the order of processing 
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does not e-f-fect the result. 



When all updates are complete. 



the user is so in-formed. When the value o-f Request_Type is 
' Casel ^update ' , the subroutine, Casel update is called. 
When the value o-f Request_Type is ' Case2__updat e ' , the 
subroutine, Case2 update is called. The Casel _update and 
Case2_update subroutines are presented in Figures 19 and 20, 
r espect i vel y . 



Subr out i ne Casel _upd ate (Request _St ac k , Resul t _Set ) 



/* Transact i on__Request : */ 

/* is a template with the Reserved word BOT */ 

/* -followed by multiple blank lines (to be used 
/* by the series o-f requests) and the Reserved */ 

/* word EOT. 



whi 1 e NOT EMPTY ( Request _Stack ) do 
Pop (Request __Stack ) 

Fill in blank lines o-f Tr ansacti on_Request with 
requests -from Request_Stack 
end wh i 1 e 

Send (Tr ansacti on_Request ) 

Recei ve (Resul t_Set ) /* Resul t_Set returned to */ 

/* calling routine */ 



end Casel_update 

Figure 19. Subroutine Casel_Update 



The Casel_Update subroutine builds a transaction 
o-f update requests for MDBS processing- The subroutine is 
provided the parameter Request_Stac k which contains multiple 
UPDATE requests stacked such that the request on the bottom 
of the stack is the request which must be processed last. 
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Subroutine Casei_Update sends the request transaction to 
MC)BS , Receives the Resuit_Set, and returns the Resuit_Set to 
the calling routine- 



SubroLitine Case2_update (Request _Stack ,Resul t_Set ) 



/* Insert_Templ ate: */ 

/* is the INSERT request with values -for the */ 

/* attr i butes— to— be— updated and blanks -for the 

/* attributes whose values are obtained by the -^ / 

/* RETRIEVE request. */ 

Send (Pop ( Request _Stack ) > RETRIEVE request -fr/ 

Recei ve ( Resul t_Set ) 

Send (Pop (Request_Stack) ) /* DELETE the record 

Recei ve (Resul t_Set > /* deletion is complete */ 

Whi 1 e there are records to update do 

Insert__Templ ate < — /* -fill in blanks with retrieved -^/ 

/* attribute values */ 

Insert_Request < — /* form the INSERT request from */ 

/* the record and I nser t_Templ ate 

Send ( I nser t_Request ) 
end whi 1 e 

Recei ve (Resul t_Set > /* INSERT is complete */ 



end Case2_update 

Figure 20- Subroutine Case2_update 



The Case2_Update subroutine controls the 
execution of the RETR I EVE— DELETE— I NSERT series of requests- 
The RETRIEVE obtains a copy of the appropriate record (s). 
The DELETE deletes the original record (s) in the database. 
The INSERT re— inserts the record (s) with all the modified 
attribute values- 

2- Retr i evi nq Qual i f i ed Groups 

Both SQL and ABDL provide an option whereby 
retrieved attributes may be grouped. For example, if we 
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wish to obtain the part number and the total quantity -for 
each part supplied, we may utilize the follov-^ing SELECT 
construct : 



SELECT P# , SUM ( QTY ) 
FROM SP 
GROUP BY P# 



The result relation is: 



p# 




PI 


600 


P2 


1000 


P3 


400 


P4 


500 


P5 


500 


P6 


100 



Note that . each expression in the SELECT clause must be 
si nql e~val ued for each group; that is, it can be either the 
GROUP_BY field itself, or a function such as SUM that 
operates on all values of a given field within a group and 
reduces those values to a single value." CRef. 91 

The above SQL operation is directly supported by the 
software structure of Chapter VI. Using the SELECT— to- 
RETRIEVE mapping which we have described in Chapter III, the 
equivalent ABDL construct is: 

RETRIEVE (FILE = SPXP# , SUM (QTY) > BY P# 

SQL provides a further option for use with grouped 
attributes- Once the rows of a table are grouped by a 
selected attribute, groups not satisfying a specified 
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condition can be eliminated through the use of the HAVING 



operator. The follov-jing compr ehensi ve example clarifies the 
use of the 'GROUP BY with HAVING' option. If we wish to 
obtain the part number and the maximum quantity of the part 
supplied for all parts such that the total quantity supplied 
is greater than 300 (excluding from the total all shipments 
for which the quantity is less than or equal to 200), we may 
use the following query: 



SELECT P#,MAX (QTY) 
FROM SP 
WHERE QTY > 200 

GROUP BY P# 

HAVING SUM (QTY) > 300 



We can imagine the result relation 



p# 




PI 


300 


P2 


400 


P3 


400 


P5 


400 



being formed as follows. A copy is made of table SP (FROM). 
The rows not satisfying "QTY > 200" are eliminated (WHERE). 
The remaining rows are then grouped by P# (GROUP BY). The 
newly formed groups are checked against the predicate 
"SUM(QTy') > 300". Those not satisfying the condition are 
eliminated (HAVING). Finally, part numbers and maximum 
quantities are extracted from the remaining groups (SELECT) - 
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a- The Translation to ABDL 

As previously discussed, ABDL provides a 
construct for the retrieval of data which is grouped by a 
selected attribute- In the compr ehensi ve SQL example above, 
the use of the HAVING operator specifies a further 
qualification on the groups. In this example, the groups 
whose total quantity supplied is less than or equal to 300 
are to be eliminated. ABDL does not provide a facility for 
checking this group condition. This condition must be 
checked in the interface. The SQL query is translated to 
the ABDL request 

RETRIEVE ((FILE = SP> A (QTY > 200)) <P# , MAX ( QTY ) , SUM ( QTY ) > 

BY P# 

which we imagine returns the following table: 



p# 


MAX (QTY) 


SUM (QTY) 


PI 


300 


600 


P2 


400 


400 


P3 


400 


400 


P4 


300 


300 


P5 


400 


400 



Software in the interface then checks the HAVING condition 
”3UM(QTY) > 300". This eliminates the grouping for part P4- 
The remaining part numbers and maximum quantities are 
returned to the user. 
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b. A Proposed Software Structure 

When SQLT returns the value, ' Gr oup_by_havi ng ' 

for the parameter, Request_Type , we assume that the HAVING 
condition is also made available to the Gr oup-By-Havi nq 
subroutine. (We make a similar assumption for other 
Request_Types) . The subroutine sends the request, receives 
the result set, checks the HAVING condition, and returns 
only those tuples satisfying the having condition to the 
user. Figure 21 depicts this operation. 

Subrout i ne Group-By— Havi ng ( Request_Stack , HAVING_condi ti on , 

Resul t_Set ) 

Send (Pop ( Request _Stac k ) 

Recei ve (Resul t__Set ) 

Eliminate groups not satisfying HAVING condition 
end Group_By_Havi ng 

Figure 21. Subroutine Group _By_Havi ng 

3- Retr i evi nq Computed Val ues 

The concept of retrieving computed values is simple, 
yet it typifies the important options that database 
management system designers are providing in order to ensure 
user — f r i endl i ness and user— f 1 ex i bi 1 i ty . This option supports 
the inclusion of arithmetic expressions involving fields as 
well as simple field— names. For example, the user should be 
able to specify un i ts— of —measure for numerical results. SQL 
supports this concept. If we wish to obtain the part number 
and the weight of the part in grams (given in table P in 
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pounds) . we may use the following query: 



SELECT P#, WEIGHT * 454 
FROM P 



The result relation is: 



p# 




PI 


5448 


P2 


7718 


P3 


7718 


P4 


6356 


P5 


5448 




8626 



a- The Translation to ABDL 

In this translation, the ABDL request retrieves 
the indicated attributes leaving any computation to be 
accomplished in the interface. For the example above, the 
ABDL translation is 

RETRIEVE (FILE= P) < P#, WEIGHT > 

The specified arithmetic operation is performed by interface 
software on the retrieved values for WEIGHT (i.e., WEIGHT ^ 
454) prior to returning the final result relation to the 
user- The software required is a simple interpreter for 
eval uat i ng ar i thmet i c ex press i ons - 

b- A Proposed Software Structure 

An Expr essi on_Eval uator subroutine can be used 
to accomplish the arithmetic operations specified in the SQL 
query- The subroutine simply utilizes the appropriate 
function (e-g., Mul t , Add , Sub , Di v) to perform the operation- 
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4. Provi d i nq Format Opt i ons 

Q-ften, the in-formation retrieved from a database is 
intended for use in published reports- The availability of 
formatting options can make generating these reports 
simpler- For example, while it is prudent to save disk 
space by storing the names of suppliers as values for an 
attr i bute— name such as SNAME- an end-user unfamiliar with 
the database is psychol ogi cal 1 y more comfortable v-jith a 
column heading such as SUPPLIERS- In SQL queries, the 

desired format is indicated in the SELECT clause- For 

example, if we wish to obtain the names of all suppliers, we 
may use the following query: 

SELECT SNAME SUPPLIERS 
FROM S 



The result relation is: 



SUPPLIERS 



Smi th 
Jones 
Blake 
Clark 



Note that the column heading is SUPPLIERS rather than the 
field name, SNAME- 

a- The Translation to ABDL 

This translation is similar to that presented in 
Subsection 2 above- Information, returned from MDBS, is 
modified by the interface software- The SQL SELECT query is 
translated to the ABDL request 
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RETRIEVE (FILE 



S) <SNAME> 



The results of this request are modified by the SQL 
interface (SQL I) prior to returning the final result 
relation to the user. In this case, the column heading, 
SNAME, is changed to the new heading, SLfPPLIERS. 
b- A Proposed Software Structure 

Format options can be provided in the Display 
subroutine. Any change in the form of the table heading can 
be passed at the time of the call to Display. 

5. The Retr i eval wi th Order i nq (SORT) 

Generally, the result of a SELECT operation is not 
guaranteed to be in any particular order- Ordering (SORT) is 
normally not accomplished in SQL queries unless specifically 
requested by the user. This operation may be costly, and 
the additional expense is often unwarranted- In SQL, the 
user may specify ordering through the use of the ORDERBY 
operator. As an example, if we wish to obtain supplier— 

numbers for all suppliers providing shipments, such that the 
result is ordered by supp 1 i er— number , we may use the 
following query: 



SELECT UNIQUE S# 
FROM SP 
ORDER BY S# 
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The result reiaticn is: 



S# 



SI 

SI 

SI 

SI 

SI 

51 

52 

52 

53 

54 
S4 
S4 



a. The Translation to ABDL 

In the translation of the above SQL query, we 
assume an ordering capability within MDBS. The development 
of this capability is the goal of a current thesis by Muldur 
CRef 153. The ABDL request 

RETRIEVE (FILE = SP) <S#> ORDER BY S# 

returns ail supplier numbers (ordered by increasing supplier 
numbers) contained in the SP file (including duplicates). 

b. A Proposed Software Structure 

We assume that the ordering of selected 

attributes is directly supported by MDBS. Therefore, no 
augmentation of SQLI is required- 

6- A |2 El i mi nat i on of Dupl i cates (PROJECTION) 

The results of a SELECT operation may contain 
duplicates. The elimination of duplicates (PROJECTION), as 
in the case of retrieval with ordering (SORT) , is normally 
not accomplished in SQL queries unless specifically 
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requested- Again, the cost is high and often unwarranted. 
An exception to this rule is that duplicate rows are 
automat i cal 1 y eliminated in UNION operations. (UNION 
operations are described in Section B) . 

In SQL, the elimination of duplicates may be 
specified through the use of the UNIQUE operator. As an 
example, if we wish to obtain supp 1 i er— number s for all 
suppliers providing shipments such that no supp 1 i er— number 
is listed more than once, and the result is ordered by 
sLippl i er— number , we may use the following query: 



SELECT UNIQUE S# 
FROM SP 
ORDER BY S# 



The result relation is: 



S# 



51 

52 

53 

54 



This example is a modification of the example presented in 
Subsection 5. Note that duplicate suppl i er— number s are 
el i mi nated . 

a. The Translation to ABDL 

The ABDL translation for the above SQL query is 
identical to the translation for our Subsection 5 example. 
Again, the ABDL request 

RETRIEVE (FILE = SP) <S#> ORDER BY S# 
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returns ail supp 1 i er-number s (ordered by increasing 
suppi 1 er —number s) contained in the SP file (including 
duplicates). Since UNIQUE is specified in the SELECT clause 
of the SQL query, SQLI must check the ordered rows 
eliminating duplicate values for the S# attribute prior to 
forwarding the result relation to the user. If our example 
is modified such that the ORDER BY clause is omitted, we may 
facilitate the elimination of duplicates by "forcing" a SORT 
of the selected attributes- That is, the ABDL RETRIEVE 
request is written to include an ORDER BY specification- 
b- A Proposed Software Structure 

When UhilQUE is specified in the SQL query, the 
Result_Set from MDBS is passed in a call to a 
Dupl i cate_El i mi nator subroutine- This subroutine scans and 
compares adjacent members of an ordered Result_Set 

eliminating duplicate members- We assume that the 

Result_Set is always ordered prior to being passed to 
Dupl i cate_El i mi nator - The ordering is either user — speci f i ed 
or "forced" in the SQLT translation. 

B. SELECTED MULTIPLE-RELATION OPERATIONS 

In this section, we discuss two additional multiple- 
relation operations which are supported by SQL: retrieval 

using the UNION operator and retrieval specifying JOIN 
operations. These two operations and the nested SELECT 

(described^ in Chapter V)’give SQL much of its power and 
flexibility- The availability of query constructs which 
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allow access to related data in multiple tables greatly 
enhances the ease with which a user can obtain the desired 
information from the database- We investigate UNION and 
JOIN operations in the following subsections- 
1 - The Retr i eval Usi nq UNION 

From set theory, we recall that the UNION of sets A 
and B (i.e., A UNION B) is the set of all objects x such 
that X is a member of A or x is a member of B. The formal 
predicate logic definition of A UNION B is: 

Vx C (X A) V (X B)J 

In SQL, the UNION operator is used in a query 
comprised of mul t i p 1 e— SELECT constructs- As an example, if 
we wish to obtain numbers for parts that either weigh more 
than 16 pounds or are currently supplied by supplier S2 (or 
both) , we may use the following query: 



SELECT 


P# 


FROM 


P 


WHERE 


WEIGHT > 


UNION 


SELECT 


P# 


FROM 


SP 


WHERE 


S# = 'S2 
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The result relation is: 



P# 



P2 

P3 

P6 

PI 



From the sample database of Chapter I, we can see that parts 
P2, P3, and P6 weigh more than 16 pounds (x Part PI 
weighs less than 16 pounds, however, PI is currently 
supplied by supplier S2 (x0B). Part P2 weighs more than 16 
pounds and is supplied by supplier S2 ((x 0A) A (x 0 B) ) . 
Note that duplicate rows are eliminated from the result of a 
UNION operation. 

a. The Translation to ABDL 

In the SQL query above, each SELECT construct 
translates into an equivalent ABDL RETRIEVE request. In 
this example, the two ABDL requests 

RETRIEVE (FILE = P) A (WEIGHT > 16) <P#> ORDER BY P# 
RETRIEVE (FILE = SP) A (S# = S2) <P#> ORDER BY P# 

are processed concur r ent 1 y . The results are combined in 
SOLI, where duplicate rows are eliminated. The remaining 
rows are forwarded to the user - 

b- A Proposed Software Structure 

When the value of Request__Type is UNION, the 
translation and processing are as follows. An MDBS SORT is 
specified in the ABDL translation. A subroutine called 
UNION pops all ABDL RETRIEVE requests off of RequestStack 
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and forwards them to MDBS for concurrent processing- 



The 



ordered result sets are merged (through the use of a 
standard merge function), and then passed to 

Dupl i cate_El i mi nator . Finally, the uniquely selected 

results of the UNION operation are returned to SQLI for 
display to the user- Subroutine UNION is presented in 
Figure 22- 

Sub rout i ne UNION < Request _S tack , Resul t__Set ) 

whi 1 e NOT EMPTY (Request_Stack ) d^ 

Send (Pop (Request_Stack ) 
end whi 1 e 

Recei ve (Resul t_Set 1 ) 

Recei ve ( Resul t __Set2 ) 

Merge (Resul t__Set 1 , Resul t_Set2) 

CALL Dupl i cate_El i mi nator (Resul t_Set ) 

end UNION 

Figure 22- Subroutine UNION 

2- The Retr i eval Spec i f yi nq Join Oper at i ons 

Join operations are char acter i st i c of data languages 
intended for use with relational databases- SQL provides 
the capability to specify implicit join, equality join, and 
inequality join operations- In an i mp licit join , attribute- 
values in multiple tables are compared , however, the values 
returned to the user are taken from only one table- 
implicit joins can be formed through the use of the nested 
SQL SELECT constructs which we have described in Chapter V- 
In the nested SELECT, multiple tables are accessed and the 
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values of selected attributes are compared- We note that 
onl>' values from the outermost SELECT are returned in the 
final result set- This operation results in the formation 
of an implicit join. 

Equal i ty join and i nequal i ty join operations are 
specified by referencing multiple tables in a single SELECT 
query. As an example of an equality join, if for each part 
supplied v^e wish to obtain part numbers and names of all 
cities supplying the part, we may use the following query: 

SELECT UNIQUE P#,CITY 

FROM SP,S 

WHERE SP.S# == S.S# 



The result relation is: 



p# 


CITY 


PI 


London 


PI 


Par i s 


P2 


London 


P2 


Par i s 


P3 


London 


P4 


London 


P5 


London 


P6 


London 



Note that table— names may be used as qualifiers in the 
SELECT and WHERE clauses in order to resolve ambiguities or 
to ensure clarity- For example, the SELECT clause mav be 
equivalently written 

SELECT UNIQUE SP.P#,S.CITY 
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Although there are optimization techniques which 
facilitate a more efficient implementation, we can visualize 
the join operation as follows- First the Cartesian product 
of SP and S is formed. Then, rov^s not satisfying the 
condition SP-S# = S-S# are eliminated- Next, columns P# and 
CITY are projected from the remaining rows- Finally, since 
the operator UNIQUE is used, all duplicate rows are removed 
before the result relation is returned to the user- (For an 
indepth discussion of the efficiency and optimization 
consi derat i ons of implementing join operations, the reader 
is referred to Demurjian CRef. 13). 

a- The Translation to ABDL 

The attr i bute—based data language, as 
implemented in MDBS, does not provide a join capability. 
liuldur CRef. 153 is currently investigating the practicality 
of i ncorporat i ng join operations within MDBS. If we assume 
that the functionality of MDBS is augmented to support the 
equality join and inequality join operations, we might use 
the following translation for the equality join (as 
discussed in Demurjian CRef- 13). The general form of a 
simple, two-way equality join expressed in the syntax of SQL 
i s 



SELECT sel _expr_l i st 

FROM r el at i on__namel , r el at i on_name2 

WHERE rel ati on_namel . attr i bute = rel at i on_name2- attr i bute 

AND qual i f i cat i on 
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The general form of the ABDL translation is 



RETRIEVE (attribute__l i st_l ) (query_l ) 

CONNECT ON ( at tr i bute_l , attribute_2) 

(attr i bute_l i st_2) (query_2) 

The sel _eKpr_l i st of the SQL SELECT is divided into a target 
list consisting of attributes from rel ati on_namei and a 
target list consisting of attributes from rel at i on__name2 . 
The qual i f i cat i on of the SQL SELECT is likewise partitioned- 
The attributes named in the equality predicate become the 
object of the CONNECT ON clause in the ABDL request - 

Following this general form, the translation for the 

equality join example of the preceding subsection is 

RETRIEVE < (S#,P#) (FILE = SP) > 

CONNECT ON (SP.S#, S.S#) 

< (S#,CITY) (FILE = S) > 

b. A Proposed Software Structure 

As stated previously, we assume a join 

capability for MDBS. Therefore, no augmentation of SQLI is 
r equi red - 

C- THE MODIFIED SOFTWARE STRUCTURE OF THE SQL INTERFACE 

In this section, we present the modified software 

structure of SQLI. We modify the structure which we have 
presented in Chapter VI in order to facilitate the 
implementation of the additional operations described in 
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this chapter. The modi-fied version o-f the top*“ievei 

process, SQLI , is shown in Figure 23- Note, we have 

simplified this algorithm through the use of the 

Request_Control subroutine- The functionality of this 

subroutine is presented in Figure 24. The purpose of 
Request__Controi is to provide overall control of request 
processing for the interface- A high-level view of the 
modified softv*jare structure is shown in Figure 25, and the 
relationship between Subroutine Request_Contr ol and its 
subordinate group of subroutines is depicted in Figure 26- 



ALGORITHM SQLI (Modified) 

Repeat 

CALL Get_SQL_Quer y (Query) 

CALL SQLT (Query , Request__Stack , N , Errors , Request __Type , 
Format__Opt i on , Ar i th^Expr ) 
i f N = O then /* Syntax Errors 

CALL Di spl ay (Query) 

CALL Di spl ay (Er ror s ) 
el se 

CALL Request_Contr ol ( Request_Stack , N , Request_Type , 

Ar i th_Expr , Resul t_Set ) 

CALL Di splay (Resul t_Set , For mat_Opt i on ) 
end i f 

End_of _sessi on? 

Lint i 1 end_of _sessi on 
end ALGORITHM SQLI (Modified) 

Figure 23- ALGORITHM SQLI (Modified) 
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SubroLit i ne Request _Control (Request __S tack , N , Request _T ype , 

Ar i th_Expr , Resui t_Set ) 



CASE Request_ 


Type OF 


CaseO_Update: 


: CALL CaseO__Update (Request__Stack , Resui t_Set ) ; 


Case i_Llpd ate: 


; CALL Casei_Update (Request_Stack , Resui t_Set ) ; 


Case2_Update; 


CALL Case2_Update (Request __Stack , Resui t_Set ) ; 


Gr oup__Havi ng : 


! CALL Group_Havi ng (Request_Stack , 

Condi ti on , Resui t_Set ) ; 


UNION: 


CALL UNION (Request_Stack , Resui t_Set ) ; 


Others: 


if N = 1 then 

CALL One_Request (Request_Stack , Resui t_Set ) 
/* for simple, di recti y— supported */ 
/* single request 

el se 

CALL N_Level _Sel ect (Request __S tack , 

N , Resui t_Set ) 

end i f 


END CASE 





Figure 24. Subroutine Request_Contr ol 
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Figure 25- 



A High-Level View of the Software Structure 





Figure 26. Requesi:_ContrDl and its Subroutines 
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VIII. 



CONCLUDING REMARKS 



In this thesis, we have concent rat ed on the 1 anquaqe 
interface aspects of using an at tri bute— based database 
system, MDBS, as a kernel for the support of the relational 
data model and the relational query language, SQL- A 
related thesis by Weishar CRef. 16D provides the design and 
analysis of an interface for the hierarchical model and the 
hierarchical data language, DL/I- This work is part of 
ongoing research being conducted by the Laboratory for 
Database Systems Research under the direction of Dr. David 
K. Hsiao- As stated in CRef- ID, the goal of this phase of 
the laboratory's research "---is to provide increased 
utility in database computers- A centralized repository of 
data is made available to multiple, dissimilar hosts. 
Furthermore, the database is also made available to 
transactions written in multiple, dissimilar data 
1 anguages - " 

The rapid evolution of database technology has provided 
the motivation for this research- Commercial database 
management systems have only been available since the 
1960's- Today, organ i z at i ons of all types are critically 
dependent on the operation of these systems. This 
dependency comes from the need to centrally control 1 arge 
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quant i ties 



o-f operational data. 



The information must be 



accurate and readily accessible by relativelv^ inexperienced 
end-users. 

There are three generally known approaches to the design 
o-f database systems. These are the network, hi erarchi cal . 
relational approaches. An organization normally chooses a 
commercial system based on one of these models. The 
database must be created and operator and user personnel 
must be trained. Because of the r e-progr ammi ng and re- 
training effort (and money) required, an organization is 
unlikely to change to a system based on one of the other 
model s. 

We have discussed an alternative to the development of 
separate stand-alone systems for specific data models. In 
this proposal , the three generally known models and their 
model -based data languages are supported by the attribute- 
based data model and data language. We have shown (in the 
relational case) how a software interface can be built for 
such support. 

Specific contr i but i ons of this thesis include extremely 
thorough explanations of SQL operations such as: set— 
membership, nested retrievals, retrieval of grouped 
attributes, join operations, retrieval of computed values, 
providing format options, retrieval using UNION, updating 
multiple fields, retrieval with ordering, and elimination of 
duplicates. We have extended the work of Nacy CRef. S3 by 
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showing that many of the SQL constructs for the above 



operations are directly supportable by ABDL and liDBS. 
Others can be translated into a series of the primary and 
aggregate operations of the attr i but e— based system- In all 
cases, SDL— to— ABDL translations are provided- We have also 
proposed a softv-^are structure to facilitate the future 
implementation of the SQL interface- 

A major design goal has been to design a SQL interface 
to MDBS without requiring that changes be made to the MDBS 
system- We have shown that the complete interface can be 
implemented on a host computer- All translations are 
accomplished in the SQL interface- MDBS continues to 
receive and process requests written in the syntax of ABDL- 
We have also shown that the interface can be designed to 
utilize existing ABDL constructs (either one or a series of 
ABDL requests). No changes to the ABDL syntax are required- 
We also have not proposed any changes to the syntax of SQL- 
We have designed the interface to be transparent to the SDL 
user- The intention is that a trained SQL user need know 
nothing of the existence of the interface or of MDBS- The 
user can log in at a system terminal, input a SQL query, and 
obtain result data in a relational format- 

In retrospect, our unconven t i onal bottom— up approach to 
design seems entirely appropriate. We have built upon the 
basic subset of SQL— to— ABDL mappings provided by Macy CRef- 
8D, making additions to the set as selected SQL operations 
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have been i ncor por ated into the interface. As our 
i nvest i gat i on begins in Chapter IV, the form of the 
interface software structure is not clear- When the nested 
SQL SELECT is described in Chapter V, the requirements for 
the structure begin to solidify. We become aware that an 
iterative structure is needed to control the processing of 
series of ABDL requests. As the algorithm, SQLI , is 
completed in Chapter VI, it is clear that we have developed 
the overall software structure for the SQL interface- The 
functionality of the structure is enhanced as additional SQL 
operations are selected- However, the general structure 
remains intact. 

As an alternative to implementing the SQL (network and 
hi erarchi cal , as well) interface on a host computer, the 
interface can be placed inside of MDBS- We have studied 
this possibility, and recommend against such an 
implementation- A major design goal of MDBS is to minimize 
the role of the controller. This goal can not be attained 
if the controller must support the operation of resident 
relational, network, and hierarchical interfaces. 

We have shown that the at tr i but e— based system supports 
relational database appl i cat i ons - We have provided SQL-to- 
ABDL translations for selected database operations, and we 
have proposed a software structure to facilitate 
implementation- The next step is to implement the interface 
on a host computer. In order to finally determine the 
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APPENDIX A: FORMAL SPECIF I CAT I ON OF THE ATTRIBUTE-BASED 

DATA LANGUAGE, ABDL 

The following is the BNF for the attri bute-based data 



language developed by Hsiao 
Square brackets C 1 are 
constructs. 

Predicate := 
attribute := 
attr i bute_bei ng_modi f i ed := 
base_attr i bute := 
value := 

Conjunct : = 

Query : = 

Stat := 
list_el := 
list : = 

Target_list := 
Attri b_val _pai r : = 
Haif_record := 

Record := 



and Menon CRefs- 4 and 101. 
used to indicate optional 

attribute rel_op value 

char_str i ng 

attr i bute 

attribute 

string 
I number 
I float 

(Predicate) 

I (Conjunct / Predicate) 

Con junct 

! Query / Conjunct 

AVG I MAX I MIN ! SUM I COUNT 

Stat (attribute) 

attribute 
; list_el 
\ 1 i st , attr i bute 

! list,list_el 

(list) 

<attr i bute , val ue> 

Attr i b_val _pai r , 

\ Half_record, Attr i b__val _pai r 
(Half record) 
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Poi nter 


: = 


number 


Mod i f i er 




type-0 
1 type-I 
I type-I I 
1 type-I I I 
1 type-IV 


type— 0 


; = 


<attr i bute_bei ng_mod i f i ed 
val ue> 


type-I 


: = 


<attr i bute—bei ng_madi f i ed 
expr 1 > 


type— I I 


: = 


<attr i bute_bei ng_modi -f i ed 
expr2> 


type-I I I 


: = 


<attri bute_bei ng_modi f i ed 
expr 2 o-f Query > 


type— I V 


; = 


< attr i bute_bei ng_mod i t i ed 
expr 2 of Poi nter > 


Request 


: = 


Insert 1 Delete 1 Update 1 
Retri eve 


Insert 


: = 


INSERT Record 


Del ete 


: = 


DELETE Query 


Update 


; = 


UPDATE Query Mod i f i er 


Retri eve 


s = 


RETRIEVE Query Target_list 
CBY attributed 
CWITH Pointer! 


uc— 1 etter 


: = 


A 1 B 1 C 1 ! 2 


stri ng 


: = 


uc_l etter 
1 string uc_l etter 


1 C“1 etter 


: = 


a 1 b 1 c ! . . - ! z 


char _str i ng 


; = 


uc_l etter 

1 char_string lc_letter 


digit 


: = 


0li:2!3l415:6 
7 I 8 ! 9 


number 


: = 


digit 

1 digit number 
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float 


:= number - number 



add_op := I — 



mul t _op 


: = * \ / 


expr 1 


:= arith_terml 

I exprl add_op ar ith_terml 


ar i th_terml 


:= ar i th_f actor 1 

I arith_terml muit_op 
ar i th_f actor 1 


ar i t h ac t or 1 


: = attr i bute_bei ng_modi f i ed 
I number 


ex pr 2 


:= arith_term2 

1 expr2 add_op ar ith_term2 


ar i th_term2 


:= ar i th_f actor2 

1 ar ith_term2 mult_op 
ar i th_f act or 2 


ar i th_f act or 2 


:= base_attr i bute 
1 number 
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